Alessandro,
There are long time solid reasons why the "Local.From" field needs to
be stable. In particular, with local messaging, unless the local
system allows for anonymous entry of the Local.From field when
creating a Local message, there is a MUST for a 1 to 1 association
with the account.
If local mail is exported for a external network, it doesn't matter
what mail network it is, you really don't want to introduce the idea
of allowing the changing of the Network.from field and making it
anonymous or disassociated with the original source. The domain is
associated with the source of the message, and the user part of the
address reflects the user account at the domain. There are good
reasons for that. Lets say the user is causing a problem on a remote
system. Using the network.From, the remote system could contact the
original system and issue a complaint. If we were "free" to remove
that idea, it be would harder to trace it. DKIM allows you to lock
that field down so that it can't be tampered with.
You have to understand the long time pov of developers that have been
at this for 40 years. Every system I have worked, the different
networks, it was the same thing -- leave the from field alone! Do not
make it "anonymous" or capable of being an "unknown."
Its the same for Instant Messaging, for Chatting, the TELEPHONE, the
Caller ID, etc, it is a TABOO to change the "From" entity.
If you want to continue your line of logic to rationalize Rewriting,
then you need to make it "protocol complete" to help keep the
association of the From field with the original source intact. But
more importantly, it should have get permission from the original
domain in order to rewrite. This can be done with a DMARC tag extension:
DMARC p=reject|quarantine ... rewrite=0|1
The default sides with highest security -- No Rewriting. But if the
domain wishes to allow for rewriting, then it should explicitly state
it in this policy record, rewrite=1.
This is something I could possibly support IFF the originating domain
allows it. There would other things to consider to tie the loose ends,
but the #1, would be the rewrite=1 tag.
--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos
On 6/18/2020 3:46 AM, Alessandro Vesely wrote:
On Wed 17/Jun/2020 21:11:31 +0200 Pete Resnick wrote:
On 17 Jun 2020, at 13:27, Dave Crocker wrote:
On 6/17/2020 9:56 AM, Pete Resnick wrote:
No, the semantics of From: have not changed generally. [...]
So, really, DMARC has altered the semantics of the From: field to
be the Sender: field.
Wait a minute: I think this point needs some clarification. We know
that the pre-DMARC semantics of the From: field are "the entity that
authored the message".
"Authoring" can have subtly different acceptations, though. The exact
sentence is:
The "From:" field specifies the author(s) of the message,
that is, the mailbox(es) of the person(s) or system(s) responsible
for the writing of the message.
[https://tools.ietf.org/html/rfc5322#section-3.6.2]
That is not so far from real. The term "writing" sounds ambiguous, as
it is not clear whether it means "typing" or "publishing", in the case
of public mailing lists. Given that Sender: is dedicated to the
typist, I'd opt for the latter interpretation.
For a newspaper, if you pardon the analogy, the masthead is more
visible than columnist signatures at the end of the articles. For a
mailing list, publisher visibility used to be provided by subject
tags, leaving the From: intact. Why? Presumably, because it just
worked that way. However, if the MLM is the system responsible for
writing, not modifying From: should be considered a violation.
My understanding of the meaning that DMARC added was, "The author of
this
message, as expressed in the From: field, always has their messages
properly
signed by the domain in the From: address." You seem to be saying
that, no,
what DMARC did was changed the semantic to be, "The From: field now
represents the transmitter of the message (as used to be expressed
in the
Sender: field when present), not the author, and that transmitter
always has
their messages properly signed by the domain in the From: address".
Sender: was not meant to be the transmitter in that sense. It was
meant to be the secretary who writes on behalf of a responsible person
or system. It never had traction, AFAIK. Most clients don't allow
secretaries to add their mailbox to the messages they write. Google
«How do I change the sender in Outlook?»
Sender ID tried to hijack Sender: —much like DMARC hijacked From:— to
introduce the concept of an entity responsible for the last hop.
DMARC requires that the last hop is also the first one, or else that
the forwarding is mechanically smooth, an unparticipated transmission
which breaks no signatures.
Mailing lists match neither case. Couldn't we consider From:
rewriting a sort of message/rfc822-wrap lite?
It may well be that X-Original-From: is not a good convention.
There's a bunch of questions to clarify, such as whether users see the
domain part of a mailbox address, whether they can tell authenticated
messages, or whether they should be trusted at all. However, unlike
Sender ID, DMARC seems to have enough success to cause a semantic
shift. If it can result in a simplified filtering, I'd accept it.
RFC 5322 says display names are "associated" to a mailbox. Certainly,
changing just the addr-spec breaks the association and wreaks havoc to
address books. The convention to write "MLM on behalf of" seems sound,
but it takes sixteen columns of real estate in the folder view. Can't
we do better?
Best
Ale
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
