In <p0610100ebc9a7bd407e3(_at_)[216(_dot_)43(_dot_)25(_dot_)67]> Pete Resnick
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
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
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
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.