spf-discuss
[Top] [All Lists]

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

2004-09-29 12:17:56
On Wed, 2004-09-29 at 11:41, Chris Haynes wrote:

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

SPF has the _meaning_ given to it in the SPF spec.  The test results are
intended for use within the mail infrastructure, not for display to humans and
are entirely 'meaningful' when used as intended.

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

You can do these sorts of verifications with sender_agents, (which I
still haven't written up into a complete spec), which is orthogonal to
the MAIL FROM and PRA credential checks of of spf and SenderID.

sender_agents is IMHO the right tool for protecting against this
particular type of phishing scheme.  The rest of spf and SenderID isn't.

I don't think I ever mentioned this in my previous posts on
sender_agents though, but the idea was that sender_agent queries asking
"does A authorize B as an agent of his?", would also give you a list of
A's valid pretty-names in that context in TXT records, (ideally another
type of RR type, but..)

(Side issue that I've been waffling on:  Normally the above answer would
be the same list as what you'd get from querying "does A authorize A". 
From's could potentially want the answer to be different, say with From:
having "Bob (by bob's friend)", where Sender: has "Bob's Friend".  The
spec could well allow a different set of pretty-name's to be used
depending on the next sender-authorized PRA, though I'm not sure if the
complication is worth it.)

In any event, this can all be handled by a modifier outside of all the
rest of SPF and SenderID, without requiring much of MUA's at all.

(Only users of MUA's that displayed *JUST* the pretty name and never the
email address would still be fully vulnerable when the initial From:'s
participated in sender_agents.)

-- 
Mark Shewmaker
mark(_at_)primefactor(_dot_)com