ietf-mxcomp
[Top] [All Lists]

Re: User experience

2004-04-07 21:37:29

In <p0610100ebc9a7bd407e3(_at_)[216(_dot_)43(_dot_)25(_dot_)67]> Pete Resnick 
<presnick(_at_)qualcomm(_dot_)com> writes:

I agree, and this is the killer one for me. If, as a phisher, all I
have to do is create a dummy domain, put "badguy(_at_)dummy(_dot_)example" in 
the
Sender, make sure there is an appropriate DNS record saying "OK to
send from this IP address saying you're from dummy.example", and put
"support(_at_)paypal(_dot_)com" in From, I've bypassed your check and you've 
done
nothing to save the poor user from me.

I think that phishers can skip the Sender: header and just go on
abusing the RFC2822 From: header.  Consider:

  From: "support(_at_)paypal(_dot_)com" <paypal(_at_)account-security(_dot_)com>

Currently, account-security.com is available for any phisher to grab,
and I'm sure that creative phishers can find many other domains to
use.

Yeah, of course, such a From: line would not fool everyone.  It might
not even fool very many, but then, most phishing catches only a few.


Validating just the domains in the various RFC2822 headers has some
value, but it will fall far short of restoring the trusted that people
used to have in email.


I dunno.  Right now, I'm thinking that a DNS entry that says "this
domain *ALWAYS* sends s/mime'd or GPG'ed email" and some changes to
the MUA to support this DNS entry would be the most effective way to
protect RFC2822 data.  I'm also thinking that I don't know enough
about the sticky details to have much confidence with that solution.


-wayne




<Prev in Thread] Current Thread [Next in Thread>