I think that what we need here is to compile an issues list.
The issue is not whether SPF is the final solution to every possible
problem. The question is whether SPF provides a solution that provides a
significant cost/benefit.
Steve does have a point, there are email clients that display only the
display name and not the email address of an email user. So SPF is not the
last word on the phishing issue.
SPF does allow us to spam filter out strings such as E-Bay Customer Support
in the subject line if they are not from the real E-Bay Customer support. At
the moment that is not possible. Sure this is ad-hoc.
BUT
* Ad-hoc fixes are what you end up doing when *
a protocol design was botched.
The IETF has had two decades to fix this, as far as
the principle victims of phishing are concerned they
will look beyond the IETF for a solution.
The high value phishing targets have a very high tollerance of cost, signing
each message is not an issue. For them a domain keys type solution would be
appropriate, tied in turn to a logotype enabled certificate and a client
that displayed the logo icon to the user as a result.
So an authentic E-Bay email would look something like
From: admin(_at_)e-bay (E-bay Customer Support) +----+ +----+
|VRSN| |EBAY|
| C3 | | |
+----+ +----+
Phill
-----Original Message-----
From: wayne [mailto:wayne(_at_)midwestcs(_dot_)com]
Sent: Saturday, January 24, 2004 11:52 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Response to the Bellovin Critique of SPF
In <20040124064243(_dot_)GG7601(_at_)dumbo(_dot_)pobox(_dot_)com> Meng Weng
Wong
<mengwong(_at_)dumbo(_dot_)pobox(_dot_)com> writes:
But you are right; some things will break. If we examined message
headers instead, we would have a different set of problems. For
example, a system that tries to authenticate the From:
header will start
out promising to protect
From: service(_at_)paypal(_dot_)com (Paypal Customer Service)
but end up vulnerable to an attack of the form
From: bad(_at_)spammer(_dot_)com (service(_at_)paypa1(_dot_)com)
That is why SPF doesn't want to get anywhere near
protecting the headers.
It isn't just something as "obvious" as bad(_at_)spammer(_dot_)com, but
phishers
could also use From: headers such as:
From: service(_at_)paypa1(_dot_)com (Paypal Customer Service)
From: service(_at_)paypalsecurity(_dot_)com (Paypal Customer Service)
From: service(_at_)paypal-email(_dot_)com (Paypal Customer Service)
From: service(_at_)paypa1-email(_dot_)com (Paypal Customer Service)
This list goes on and on.
Phishing is going to be very hard to stop. However, comparing the
envelope-from with the From: header goes a very long ways.
The cases where this fails are things like mailing lists and
forwarders. While those cases are hard to solve *in general*, for a
specific user, these can usually be figured out automatically. People
just don't subscribe and unsubscribe to mailing lists that often, and
they don't switch forwarders very often. Simply noting a history of a
user receiving mistmatched froms using given envelope-from domain is
is going to be very effective.
SPF validated envelope-froms are also very easy to check against
RHSBLs, This means that phishers can't create the history of
mismatched froms.
-wayne
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily
deactivate your subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡