John Levine wrote: >> >> This is *NOT* about protection or authentication, this is purely about >> rfc822/2822/5322 message semantics. Something that has been well-defined >> and constant for decades. > > I have considerable sympathy in theory for your viewpoint, but in > practice, the Sender header was deprecated a long time ago. Most MUAs > ignore it, the few that don't display it in a way that just confuses people. According to _what_ standard do MUAs interpret the semantics of EMail then? AFAIK, the relevant standard that the IETF published for this purpose is rfc5322, and in that specification, Sender: is alive and kicking just the way it has been since rfc822. https://tools.ietf.org/html/rfc5322#section-3.6.2 If the originator of the message can be indicated by a single mailbox and the author and transmitter are identical, the "Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD appear. Now if you're wonding what that "SHOULD" in there means, there is a reference to rfc2119 at the beginning of rfc5322, (a pretty common reference in IETF specifications...) https://tools.ietf.org/html/rfc5322#section-1.2.1 1.2.1. Requirements Notation This document occasionally uses terms that appear in capital letters. When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD NOT", and "MAY" appear capitalized, they are being used to indicate particular requirements of this specification. A discussion of the meanings of these terms appears in [RFC2119]. which leads to https://tools.ietf.org/html/rfc2119#section-3 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. MUAs that goof the semantics of the "Sender:" header field are either not implementing EMail the way it has been specified by the IETF, or they goofed the second part of the above explanation for SHOULD. -Martin