First, it's just plain wrong to generally rely on the "From:" header. To determine the alleged sender address (it cannot be the *true* sender since it is easily forgeable), you may rely on the "From:" header exactly as long as there is no "Sender:" header. Regardless of how often that is the case, if there is a "Sender:" header, you *must* consider its value over the "From:" header as the alleged sender address. There's simply no point in arguing about that.
You might want to always consider the "From:" header the sender address *for simplicity of code*, but be aware that it's just plain wrong.
Tell that to all the people that write clients. Outlook 2000 MAY support it, but many don't. Most webmail systems and Apple Mail (what I use) doesn't. It may be plain wrong, but it happens a lot. (As evidenced by this message going to the wrong address...)
Likewise, MIME should be formatted a certain way, but 99% of programmers seem to be unaware of this, judging by the number of automated messages that get wrapped by courier.
Second, IMO it *does* make sense to rely on the envelope sender if you somehow verify its validity (using sender authorization schemes or anti-forgery schemes like SPF, or maybe even Yahoo's DomainKeys) and then overwrite any existing "Sender:" header with it, optionally adding an "X-Message-Flag:" header as a warning if the original "Sender:" header contained a differing address. This methodology can even be a tool against phishing (visually faking the "From:" or "Sender:" addresses, e.g. "[EMAIL PROTECTED]" or "[EMAIL PROTECTED] <[EMAIL PROTECTED]>").
That's a good point. I know my domain has SPF, though I don't actually run any spf checks yet. I'm considering installing Courier::Filter's SPF filter. If a filter that processed the envelope sender and rewrote the Sender: header existed, I would probably use it. It's useful to know.
--
Phillip Hutchings
[EMAIL PROTECTED]
http://www.sitharus.com/
smime.p7s
Description: S/MIME cryptographic signature
