[Michel Py]
First, I send myself some email. The good old fashioned way, with
telnet:
http://home.pacbell.net/arn-py/photos/telnet_25.jpg
(who needs an email client, anyway?)
Well, you have no FROM email address in there at all, only a display
name. It's not surprising to me that only the display name is shown by
any mail client.
As you hinted, even the latest Mozilla Thunderbird (8.0) has the same
issue:
http://web.bai.org/temp/MozFromName.jpg
I sent my test message with telnet as well, but you can actually
configure a surprisingly large number of mail clients to send mail this
way. I know it was possible to have an entirely blank From email and
display name on older versions of Netscape mail; I'm not sure if that
behavior has carried forward into Mozilla or not.
This is exactly why I think we need RFC-2822 integrity checking and
authorization as part of some transport-level standard like Unified SPF.
There are too many MUAs out there for us to change; changing MTA
behavior to stop this problem is much easier.
I actually think rewriting the RFC-2822 From and Sender headers to match
envelope sender, while drastic, is an approach worth investigating. It
stops this sort of header nonsense (and the resulting phishing) quite
well.
We could even rewrite the From display name with the proper warning text
describing the situation. For example, the above example could have its
RFC-2822 header rewritten as:
From: "bai.org sender claiming to be Bill Gates" <rmalayter(_at_)bai(_dot_)org>
The bai.org part if verified by (presumably) SPFv1, everything else is
suspect and labeled as such.
Other than mailing lists, what legitimate mail functions would such
rewriting behavior break? I can't foresee it being much of a problem,
since we could leave the reply-to headers intact.
SPFv1 + "from header rewriting" would seem to fix a lot of MUA-related
issues... I just can't think of everything it might screw up.
Regards,
Ryan
