spf-discuss
[Top] [All Lists]

RE: Re: DEPLOY: SPF/Sender ID support in Courier.

2004-08-30 12:17:08
Maybe SPF spec should be able to verify all of the headers?
Or at least more of them!

Maybe something like this:
phredsmailservice.com. TXT "v=spf1 mx alias:bankofamerica.com -all"

No that won't work.


I guess the MTA should/could verify the other headers which would require
that bankofamerica.com. have an SPF record that allows mail from
"phredsmailservice.com.".

bankofamerica.com. TXT "v=spf1 mx include:phredsmailservice.com."

Then the MTA would check that "sender:" and "from:" are valid for the domain
"phredsmailservice.com." and/or "bankofamerica.com.".

Guy

-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of Holm, 
Mark
Sent: Monday, August 30, 2004 1:09 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] Re: DEPLOY: SPF/Sender ID support in Courier.

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

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in Atlanta features
SPF and Sender ID.
To unsubscribe, change your address, or temporarily deactivate your
subscription, 
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com