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