The significant problem I see with depending upon the authorized PRA
Mailbox Domain for assessing complaints is that this identity has not been
authenticated. What the PRA Mailbox Domain provides is whatever can be
deduced about the message emerging from an otherwise anonymous MTA where
only the IP address is certain. If one were to expect that when a PRA
Mailbox Domain is using an MTA with a decidedly blacklisted IP address,
then by extension all the published MTA addresses for this PRA Mailbox
Domain should be blacklisted. That would be a fatal conclusion.
It would be difficult to conclude anything about the message content which
formed the premise for the PRA Mailbox Domain while the trustworthiness of
the MTA remains unknown. Is this domain using an "open-ended" list? Is
this a shared MTA? Is the recipient's mail relay secure. Has all the MTA
servers performed the required PRA Mailbox Domain to Mail Channel
prescription checks? It gets ugly. There will be an endless array of
fingers pointing in every direction, but the domain being harmed by the
reputation assertion will be pointing their finger at the reputation
service.
There is far too much uncertainty in this for any assertions to be applied
with respect to a Mailbox Domain against a Mail Channel prescription other
than to say the message is authorized or not. It would even be dangerous
to treat "authorized" as having any great significance. It is vital for a
reputation service that the identity used be authenticated and not just
authorized. In other words, is it reasonable to assume this entity is the
bad actor? Some may take the attitude they should find a better mail
provider should they get listed. It may not have been their mail provider
at fault however. Mail gets relayed through administrative domains where,
at any point, there may be a lapse in control over access to the mail
channel.
This is why it is vital that reputation services be built upon the CSV
results, rather than depending upon the Sender-ID identity to serve this
function. If the expected outcome of all the finger pointing results in
the routine insertion of a Resent-From header, then there is virtually no
difference between the identities being used between CSV and Sender-ID at
that point. There is a significant difference in the strength of the
authentication of these identities however. CSV isolates the
authentication to a single administrative domain. Sender-ID may isolate
the authentication to hundreds of administrative domains. This is a huge
difference when one is attempting to block the bad actor, but where the
bad actor may be masquerading as one of any of these administrative
domains. Worse yet, if there is an "open-ended" list used, then the bad
actor could be anyone regardless of the level of certainty obtained from
Sender-ID due to the problem of "validation promotion".
-Doug
I don't think this is by any means a trivial task, though.
-Jim
At 07:15 PM 8/27/2004 -0400, John Leslie wrote:
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?