spf-discuss
[Top] [All Lists]

Re: A hole in planned phishing-prevention?

2004-06-03 14:47:20
On Thu, 3 Jun 2004, Ryan Malayter wrote:

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?

We should rewrite the MUA to deal with this. The correct information has 
been provided to the user. Perhaps the MUA should say "Allegedly on behalf 
of".

You are suggesting that the SMTP protocol be made responsible for the 
stupidity of the user. This is not the purpose of SMTP.

S.

-- 
Shevek                                    http://www.anarres.org/
I am the Borg.                         http://www.gothnicity.org/