spf-discuss
[Top] [All Lists]

Re: [SPFTAG] - RE: [SPFTAG] - RE: No use of checking RFC2822 headers - Sender is probably forged (SPF Softfail) - Sender is probably forged (SPF Softfail)

2004-09-29 11:58:12
In <0d5301c4a63a$d07810a0$0200000a(_at_)ringo> "Chris Haynes" 
<chris(_at_)harvington(_dot_)org(_dot_)uk> writes:

 <terry(_at_)ashtonwoodshomes(_dot_)com> declared:
<snip>


And in order to make SPF meaningful, we have to SHOW the verified domain to
the user, hence get rid of "pretty names" [...]


IMHO this thread has got _way_ out of line with the intent of SPF.

[...]

Please don't try to contort SPF into some kind of anti-phishing scheme.

Since almost the beginning, people involved in the SPF project have
wanted to stop all sorts of email forgery.  If you look at the SPF
spec from around a year ago, you will see a "scope=" modifier that
would allow checking of either the 2821.MAILFROM identity or the
2822.From: identity.  Many of us wanted then, and still want now, to
extend SPF into the anti-phishing (2822.From:) area.

The reasons why the "scope=" modifier was dropped and we fell back to
just checking the 2821.MAILFROM and 2821.HELO identities are:

1) We realized that we couldn't think up a reliable way of checking
   the 2822.From: header in face of current oprations of mailing lists
   and such.

2) We realized that most anti-phishing schemes would require changes
   to the MUAs, and none of us have enough influence on that area to
   get folks like MS (Outlook) or AOL/Yahoo/Hotmail to change their
   systems.

3) It was hoped that we could extent SPF into the 2822.From: without
   having to resort to explicit scoping information.


While I think we do, indeed, need to get a much firmer spec on
SPF-classic, I don't think we should stop thinking about how to extend
SPF to be useful in the anti-phishing area.  Work on this area usually
goes by the name of Unified-SPF.  This doesn't mean that SPF actually
has to directly solve the 2822.From: forgery problem.  Things like
adding a modifier that says that email from the domain is *always*
signed via domainkeys would work.  (E.g. dk=always)


Personally, I do not consider the PRA to be particularly useful in the
anti-phishing area, but if MS is only willing to change Outlook to
show the PRA, then the PRA is better than nothing.  Well, a PRA with a
reasonable license is better than nothing.  The PRA with the current
license is worse than nothing.


-wayne