spf-discuss
[Top] [All Lists]

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

2004-08-30 15:34:54
Didn't arrive first time - so trying  again :-/

----- Original Message -----
From: "jpinkerton" <johnp(_at_)idimo(_dot_)com>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Monday, August 30, 2004 9:49 PM
Subject: Re: [spf-discuss] Re: DEPLOY: SPF/Sender ID support in Courier.



----- Original Message -----
From: "Holm, Mark" <MHolm(_at_)medrad(_dot_)com>

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.



That's an excellent synopsis Mark :-)

I would like to add that the Algorithm from ...-pra.txt is basically going
down the headers looking for malformed or multiple entries, which it will
reject, until it comes up with a "clean" one, which will be from the last
"resender" in a train of forwarding hops, and it checks the validity of
that
specific header only.  The form of the check is not yet decided, and it
might possibly be spf, but it could equally easily be a reputation/rating
service.

The upshot is that I agree with you - Sender-ID is no better than spf in
reality.  Well - we'll see what it's like in reality when it's deployed.
It's got a awful lot of ground to cover before it's as proven as SPF.
 Sure - spf has some problems to sort out with sub-domains and "unkown" or
"flexible" forwarding, but at least there's something to actually work
with
to get around these issues.

Just a thought - but it is likely that Meng Wong was taking a calculated
risk in courting MS in order to get them "on board".  There's been some
excellent work done in getting SPF adopted with some major names, and MS
were an obvious name to get.  Unfortunately their corporate philosophy
does
not include open source, so it was inevitable that there would be an
attempt
to usurp the work already done.

Meantime - we *must* protect spf from all and any attempts at licensing -
even if it's by default, or incidental inclusion.  Hence my personal
stance
against the MS licence issue -
a.    It's an obvious technology - so the patent application should be
void
b.    It appears that there's prior art - so the patent application should
be void
c.    There is no apparent benefit over SPF-classic (once SPF-classic has
sorted out the remaining issues) - so why bother?


Slainte,

JohnP.
johnp(_at_)idimo(_dot_)com
ICQ 313355492