"Ryan Malayter" <rmalayter(_at_)bai(_dot_)org> writes:
I just thought of something...
[...]
My mother could be fooled by this, thinking phisher.com was somehow
associated with her bank.
I agree 100%. You might also want to check out the thread started on
Wed, 26 May 2004 with the Subject "RFC 2822 groveling after flag day".
The answers I've received so far seem to be:
1. SPFv1 isn't intended to fix phishing, but someday a crypto addition
like DomainKeys could do it.
2. MUAs should display both the purported responsible address and the
submitter address (the resender) and users will be smart enough or
can be educated to understand this.
3. MUAs should be rewritten to distinguish between relayed and
non-relayed mail and users will be educated to know that, for
example, your bank's email will always have a green light, border, or
fuzzy mascot.
why I'm still harping on this:
1. isn't here now and DomainKeys does have some deployment problems for
certain widely-used MTAs/MUAs
2. uh-huh
3. deployment problems
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?
Good question.
Maybe we re-write the RFC-2822 From: header in some way to prevent this?
Maybe (I assume you mean rewriting when (MAIL FROM != SUBMITTER) ||
(!defined SUBMITTER)), but I need to think about this some more.
It would definitely be more scary-looking which is _good_.
Daniel
--
Daniel Quinlan
http://www.pathname.com/~quinlan/