Stuart D. Gathman wrote:
<snip>
But I still don't understand how senderID meaningfully authenticates anything
in the
RFC2822 headers. Perhaps I'm just dense - or perhaps the Emperor is naked.
</snip>
I'm not sure he is completely naked, but a lot of skin is surely showing! IMO,
SenderID is able to say one thing and one thing only: The ip address from which
this message came is on the approved to send list at the domain of one of the
headers checked by the PRA algorithm. This is purported to be somewhat more
powerful against phishing attacks than a similar SPF Classic check. My own
thinking indicates that it will be no more powerful against phishing attacks
than SPF Classic. Why?
SenderID proponents say that it is more powerful against phishing because it
validates an RFC 2822 header, the type of header users actually have a chance
of seeing with most email clients. Is this practically true? I think not.
Consider the following example:
Phred Phisher controls domain prhedsmailservice.com which has an outbound
mail server at 123.123.123.123 phredsmailservice.com has a senderID record in
DNS (whatever form these end up taking) that includes the ip 123.123.123.123
Phred sends messages from 123.123.123.123 like this:
Resent Sender: bankofamericamailingservice(_at_)phredsmailservice(_dot_)com
other useless headers here
From: president(_at_)bankofamerica(_dot_)com
Dear sucker,
Please send all your worldly goods and chattels to the following website
http://phredssitedisguisedasbankofamerica.com
Thank you.
Pres
P.S. Bank of America has contracted with Phred's Mail Service, Inc. to send
these messages. Messages will have a Resent Sender header
bankofamericamailingservice(_at_)phredsmailservice(_dot_)com
This message will pass Sender ID (and, if Phred was careful with his RFC 2821
headers, SPF Classic too.) If someone will be taken in by the first part of
this message, why not by the second? It is very common for large banks and
other corporations to outsource tasks. My credit card companies' legitimate
snail mail comes from and goes to cities all over the U.S.
But, you say, Phred will have to send from a domain he controls and that makes
him more traceable. True, but equally true of SPF Classic and neither makes
the recipient of the message any better off. A recent news article noted that
phishing web sites are typically being closed down in 3-4 days, yet they manage
to do significant mayhem in the meantime. Phishing web sites also have to be
controlled by Phred or his ilk, and they are just as traceable as the domain
Phred mails from. Net gain from Sender ID: Pretty darned small if you ask me.
SPF Classic accomplishes the same thing, making Phred use a traceable domain
to mail from, with a smaller footprint and less room for error.
SenderID and SPF Classic are both attempts to ameliorate a social problem with
a technical fix. Neither can be completely successful by itself. Both must be
evaluated in a social context, as I have done above. The big question is not,
does SenderID or SPF work technically, but how do they work in the social
context? My answer is that SenderID is no better socially than SPF and SPF is
better technically.
Mark Holm