I would suggest DMARC usage of the 5322.From because it was a carry-on
from the original DKIM SSP Built-in Model which did used the Author
Domain was a strong anchor and also the last RFC53212 anchor identity
NOT expect to changed and be modified. ADSP carried it on and so did
DMARC -- it is the DKIM Policy Model.
Think about it. Your email is a legal copyright document. The Author
Identity is very important here -- legally. Changing the From can be
technically and legally argued as a 1986 US ECPA mail tampering
violation hence, any deviation from the expected norm is subject to a
negative classification.
Yes, the MUA displaying it was all part of the end to end expectation
for MAIL frameworks since day 0 of electronic mail communications that
predated RFC822-- no one should ever expect the author identity to
change in copyrighted messaging material. It is unthinkable and for
these reason, the 5322.From identity is the only header required to be
bound to the DKIM hash signature.
That is why 5322.From was chosen as the only logical option. There is
no other header in 5322 that is expected to remain persistent once
created. Maybe the internal Message ID is another but without a
doubt, the Internet Email Network 5322.From or Any-Mail-Network.From,
even a Chat, even an instant message, there is no expectation that it
is expected to be changed -- ever.
That is why, in my very strong ethical mail engineering opinion, as a
developer since Fidonet, the rewrite was the biggest "goof" in the
annals of Email history --- it ruined the ability for DMARC to ever
fix the problem -- because we opened the door to rewrites as the path
to least resistance to the DKIM POLICY (NOT DMARC) integration with
mailing list problem. There are ways to fix the rewrite problem.
But it seems to be too late for even that.
Thanks
On 3/24/2021 7:54 AM, Ken O'Driscoll wrote:
Hi Charles,
DMARC is intended to prevent unauthorised use a domain name in the
5322.From header. This header was chosen because it is displayed in
MUAs and is the target of spoofing attempts in phishing campaigns. I
agree that there is some ambiguity in the original RFC but the
intention is clear - DMARC exclusively works on 5322.From by design
not oversight.
The interoperability issues between DMARC and mailing lists etc. are
well understood and documented (for example, see
https://www.rfc-editor.org/rfc/rfc7960.html) and the underlying
protocols where the policy get applied, namely SPF and DKIM, already
had interoperability issues with intermediaries even before DMARC
came along.
There is actually an existing working group draft discussing
extending DMARC to incorporate the 5322.Sender header, see
https://datatracker.ietf.org/doc/draft-ietf-dmarc-sender/. That
document goes into considerable detail on how 5322.Sender could be
incorporated in the future.
Ken.
*From:*dmarc <[email protected]> *On Behalf Of *Charles Gregory
*Sent:* Wednesday 24 March 2021 09:49
*To:* [email protected]
*Subject:* [dmarc-ietf] Sender vs From Addresses
I’m having trouble with DMARC prioritizing the From address over the
Sender address. Couldn’t a future version at least allow this
behavior to be modified with the DNS entry or something?
I found my issue well articulated in the thread copied below and
completely agree with this gentleman.
Thoughts???
Taken from: email - Why does DMARC operate on the From-address, and
not the envelope sender (Return-Path)? - Server Fault
<https://serverfault.com/questions/753496/why-does-dmarc-operate-on-the-from-address-and-not-the-envelope-sender-return>
----------------------------------------
1.Why was DMARC designed that way?
·because the people who designed it apparently didn't read section
3.6.2 of RFC 5322
<https://tools.ietf.org/html/rfc5322#section-3.6.2>, or
misinterpreted it, or ignored it.
That section clearly establishes that a |Sender:| header, when
present, takes priority over a |From:| header, for the purposes of
identifying the party responsible for sending a message:
The "Sender:" field specifies the mailbox of the agent responsible
for the actual transmission of the message. For example, if a
secretary were to send a message for another person, the mailbox of
the secretary would appear in the "Sender:" field and the mailbox of
the actual author would appear in the "From:" field. 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.
Contrast this with the rationale given in RFC 7489
<https://tools.ietf.org/html/rfc7489#section-3.1>:
DMARC authenticates use of the **RFC5322.From** domain by requiring
that it match (be aligned with) an Authenticated Identifier. The
**RFC5322.From** domain was selected as the central identity of the
DMARC mechanism because it is a required message header field and
therefore guaranteed to be present in compliant messages, and most
Mail User Agents (MUAs) represent the **RFC5322.From** field as the
originator of the message and render some or all of this header
field's content to end users.
I contend that this logic is flawed, as RFC 5322
<https://tools.ietf.org/html/rfc5322#section-3.6.2> goes on to call
out this error explicitly:
Note: The transmitter information is always present. The absence of
the "Sender:" field is sometimes mistakenly taken to mean that the
agent responsible for transmission of the message has not been
specified. This absence merely means that the transmitter is
identical to the author and is therefore not redundantly placed into
the "Sender:" field.
I believe that DMARC is broken by design, because
·it conflates //authority to send// and //proof of authorship//;
·it misinterprets prior RFCs, and
·in doing so it breaks any previously compliant list-serv that
identified itself by adding its own |Sender:| header.
If a |Sender:| field is present, DMARC should say to authenticate
//that// field and ignore the |From:| field. But that's not what it
says, and therefore I consider it to be broken.
RFC 7489 <https://tools.ietf.org/html/rfc7489#section-3.1> continues:
Thus, this field is the one used by end users to identify the source
of the message and therefore is a prime target for abuse.
This is simply wrong (in the context of justifying ignoring the
|Sender:| header). At the time that DMARC was designed, common email
clients would routinely display a combination of the information
from |Sender:| and |From:| fields, something like **From
**/*/name-for-mailing-list@server/*/** on behalf of
**/*/[email protected] <mailto:[email protected]>/*/. So it
was always clear to the user who was responsible for sending the
message they were looking at.
----------------------------------------------------------------------
Suggestions that |Reply-To:| is an adequate replacement are also
flawed because that header is widely misinterpreted as "additional
recipient" rather than "replacement recipient", and replacing the
original sender's |Reply-To:| would impair the functionality for
//those// users.
*Charles A. Gregory*//
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
