ietf-mxcomp
[Top] [All Lists]

Reputation services for SenderID

2004-08-27 16:15:30

Jim Lyon <jimlyon(_at_)exchange(_dot_)microsoft(_dot_)com> wrote:
On Thursday, August 26, 2004 at 5:07 PM, Douglas Otis wrote:

The Identity being authorized is the PRA Mailbox Domain by way of
reference to a Mail Channel prescription of IP addresses.

No, please try reading it again. The identity being authorized is the
sending MTA's IP address.  The action being authorized is to send a
message on behalf of the PRA.  The organization doing the authorization
is the domain of the PRA.

   Jim is exactly right.

   The SPF2 record specifically authorizes a list of IPs to send mail
on behalf of the domain part of the PRA.

   CSV, on the other hand, authorizes a specific host-name to send mail
as directed by the domain which that host-name belongs.

   Actually, these two functions are remarkably similar: both are
optimized to validate the last hop before the recipient domain; neither
validates a field ordinarily seen by the recipient of the email.
Why are we arguing which way is better?

   Doug and I both came into this WG concerned about reputation services.
We both looked at the SPF record format and despaired of designing a
system of reputation services which could say whether a SPF domain is
worth trusting. We backed away from that and looked at a hop-by-hop
reputation service. This we believed was practical. Our design can be
found in the CSV documents.

   I've been mostly quiet during the SenderID discussions, feeling I
don't have much to add. Doug has put forth ideas as they occur to him;
sometimes passing them by me first, sometimes not. I wish people were
more receptive to his ideas; but that's not the purpose of this email.

   As the discussion has progressed, I've learned how similar to CSV
SenderID actually is. I now believe a system of reputation services
could be designed for it. But I'm not sure anyone would like it.

   We start by agreeing that the exact domain-part of the PRA is the
unit to be accredited; and presume some (unspecified) DNS lookup for
reputation information.

   We then evaluate the list of IPs authorized by the SPF2 record,
and run them against known IP blacklists; accumulating a score based
on weighting the reputation of those blacklists for spam identified,
false negatives, and false positives.

   Now the part you probably won't like: we must assign low weighting
to blacklists with high false negatives, while we can't assign low
weighting to blacklists with moderate false positives. Worst of all,
we can't assign any positive score to IP addresses not on any blacklist.

   Thus, in essence, we'll be producing ratings _highly_ correlated
with the number of IP addresses authorized by the SPF2 record, and
even for domains which only authorize a very few IP addresses, we'll
have no practical way (except manual processing of requests) to
correct outdated blacklist listings.

   We can, of course, include the suggested-service features of the
CSV proposal, but the reputations of suggested services would have
to be pretty-darn-good to outweigh the algorithm listed above.

   Can anybody design a better system of reputation services for
SenderID?

--
John Leslie <john(_at_)jlc(_dot_)net>