spf-discuss
[Top] [All Lists]

A hole in planned phishing-prevention?

2004-06-03 13:54:45
I just thought of something...

If we're going to allow the new SPF to fall back to using RFC-2822
headers to figure out responsible sender, we have to be careful.

Unless I'm missing something, a message with these properties:

   ENVELOPE-SENDER: someguy(_at_)phisher(_dot_)com  (no RFROM)

   RFC-2822 From: Operations(_at_)FirstNationalBank(_dot_)com
   RFC-2822 Sender: someguy(_at_)phisher(_dot_)com

will pass under the new SPF, assuming phisher.com has valid SPF records.
The responsible sender will be evaluated as phisher.com. The message
will display in many MUAs as something like:

   From: someguy(_at_)phisher(_dot_)com on behalf of
Operations(_at_)FirstNationalBank(_dot_)com

My mother could be fooled by this, thinking phisher.com was somehow
associated with her bank.

Is there a way to prevent this by changing the logic we use to determine
responsible sender in the new SPF? That is, without changing
widely-deployed MUA behavior? But still allowing for legitimate
send-on-behalf type messages?

Maybe we re-write the RFC-2822 From: header in some way to prevent this?

Regards,
        Ryan