Subject: [dmarc-ietf] Sender vs From Addresses

From: Charles Gregory <[email-masked]>
Date: Wed, 24 Mar 2021 09:48:47 +0000

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-masked]. 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

---

From: Ken O'Driscoll <[email-masked]>
Date: Wed, 24 Mar 2021 11:54:49 +0000

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-masked]> On Behalf Of Charles Gregory
Sent: Wednesday 24 March 2021 09:49
To: [email-masked]
Subject: [dmarc-ietf] Sender vs From Addresses

Thoughts???

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-masked]<mailto:[email-masked]>. So it was always clear to the user who was responsible for sending the message they were looking at.

Charles A. Gregory

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Mar 2021 06:55:18 -0700

On 3/24/2021 4:54 AM, Ken O'Driscoll wrote:
> 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.

It was also chosen because it is the only identification field that is 
always present.

As for display to user, there is no evidence that validating the field 
has any effect on end-user susceptibility to phishing.  It seems natural 
that it would; however in fact there is evidence that it doesn't.  
Still, the belief that it does persists.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

Volunteer, Silicon Valley Chapter
Information & PLanning Coordinator
American Red Cross
[email-masked]

---

From: Hector Santos <[email-masked]>
Date: Wed, 24 Mar 2021 12:58:25 -0400

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:
> 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-masked]> *On Behalf Of *Charles Gregory
> *Sent:* Wednesday 24 March 2021 09:49
> *To:* [email-masked]
> *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?
>
> 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.
>
> ·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-masked] <mailto:[email-masked]>/*/. 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-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Mar 2021 10:26:46 -0700

On 3/24/2021 4:54 AM, Ken O'Driscoll wrote:
> 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/ 
> <https://datatracker.ietf.org/doc/draft-ietf-dmarc-sender/>. That 

To be possibly overly frank, I think the draft is stalled.  Given 
existing practice, there are challenges to fielding this, for 
incremental adoption, in a way that is reasonable and useful. (The 
Internet does not support 'flag' days.)

I am still, sometimes, mulling over the choices for this, but so far 
haven't come up with (or seen) ways to resolve the challenge.

An option the working group declined to pursue is to define an Author: 
field and leave the From: field to the 'handling' role DMARC has 
relegated it to.  The draft for this is being pursued outside of the 
working group.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Hector Santos <[email-masked]>
Date: Wed, 24 Mar 2021 14:17:13 -0400

On 3/24/2021 1:26 PM, Dave Crocker wrote:
> To be possibly overly frank, I think the draft is stalled.� Given 
> incremental adoption, in a way that is reasonable and useful.� (The 
> An option the working group declined to pursue is to define an 
> Author: field and leave the From: field to the 'handling' role DMARC 
> has relegated it to.� The draft for this is being pursued outside of 
> the working group.
>
>

As I as always said with all our decision points, like this one -- if 
we are changing a well-used protocol, still in informational state and 
we are seeking a standard track, we need to provide more options. With 
all these rough decision they are ideal for making it optional.  So if 
you want a particular operation to expose a public policy that says 
"Sender" is in some formal protocol language way, is more important 
than "From" then there is no reason why we can not define those 
protocol rules.  But right not, DMARC is too limited. We must exploit 
and expand section 3.1.3 for advanced DMARC methods:

3.1.3.  Alignment and Extension Technologies

    If in the future DMARC is extended to include the use of other
    authentication mechanisms, the extensions will need to allow for
    domain identifier extraction so that alignment with the RFC5322.From
    domain can be verified.

This is whats holding us back --- trying to "correct" the current 
informational spec WITH words and no protocol improvements whatsoever.

So what is the rule for Sender? I'll support it if it makes sense. If 
sender is used, there SHOULD be some author policy tag indicating so.

-sender=1

means to follow your specs?

---

From: Charles Gregory <[email-masked]>
Date: Wed, 24 Mar 2021 18:17:30 +0000

Thank you for the replies gentlemen.  This draft exactly what we are needing!

Responsible users want to be able to send to e-mail lists as themselves and have replies go to themselves while bounces go to a central system inbox ([email-masked]) return-path address for processing and database cleanup - without risk of lower deliverability rates.

Honestly, I can't believe this wasn't considered.

I realize changes like this take a long time to roll out / be adopted; but what's involved in getting this "unstuck?  Honestly I have no idea how these things happen.

Charles Gregory

Sent from my T-Mobile 4G LTE Device

-------- Original message --------
From: Dave Crocker <[email-masked]>
Date: 3/24/21 1:27 PM (GMT-05:00)
To: Ken O'Driscoll <ken=[email-masked]>, Charles Gregory <[email-masked]>
Cc: IETF DMARC WG <[email-masked]>
Subject: Re: [dmarc-ietf] Sender vs From Addresses

To be possibly overly frank, I think the draft is stalled.  Given existing practice, there are challenges to fielding this, for incremental adoption, in a way that is reasonable and useful.  (The Internet does not support 'flag' days.)

I am still, sometimes, mulling over the choices for this, but so far haven't come up with (or seen) ways to resolve the challenge.

An option the working group declined to pursue is to define an Author: field and leave the From: field to the 'handling' role DMARC has relegated it to.  The draft for this is being pursued outside of the working group.

d/

--
Dave Crocker
[email-masked]<mailto:[email-masked]>
408.329.0791

Volunteer, Silicon Valley Chapter
Information & PLanning Coordinator
American Red Cross
[email-masked]<mailto:[email-masked]>

---

From: Douglas Foster <[email-masked]>
Date: Wed, 24 Mar 2021 21:24:53 -0400

>
> Calendar invites are a special case which requires a task-specific
> solution.
>
> The larger problem is with forwarding.   Forwarders want a way to reliably
> identify themselves so that their forwarded traffic is given a favorable
> reputation.   Authentication based on the “Sender” header is one variant on
> this objective.    The theoretical obstacles to this goal are substantial.
>
> For a general solution, we must assume that the forwarder receives a
> message stream which includes both wanted and unwanted messages.     We can
> also assume that the forwarding organization and the final recipient
> organization have different spam filtering rules.
>
> If the filtering rules of the forwarding organization are stricter than
> the receiving organization, then the recipient will miss some messages that
> should actually be delivered, leaving both originator and recipient feeling
> unhappy with the forwarder.   In the general case, this incents the
> forwarding organization to have relatively weak filtering rules.
>
> In the more likely case that the filtering rules of the forwarding
> organization are weaker than the recipient organization, then the
> forwarding organization will accrue a reputation as unreliable, the source
> of some spam.
>
> Additionally, the process of forwarding hinders the ability of the
> recipient organization to filter based on the actual sender.    The process
> of forwarding hides the message source behind the forwarder identity,
> obscuring information that would have been used to evaluate the message if
> it had been sent directly.  Consequently, we have a message source that is
> known to send some spam, combined with insufficient tools for
> distinguishing between trusted and malicious originators.
>
> To solve these problems, a forwarded message will need to be evaluated
> using both the forwarder identities and the originator identities.    That
> process will require scanning the entire header structure, particularly the
> entire Received chain, which should then be correlated with any changes
> made to the RFC5321.MailFrom address or RFC5322.From address.   My opinion
> is that the current header structure lacks the identifiers necessary to do
> this correlation, even if the submitting servers are eager to supply
> whatever is desired.
>
> The trust problems are aggravated by the inability to verify the accuracy
> of the Received header, SRS rewrites, or mailing list modifications.    If
> recipients begin using unverifiable header elments for whitelisting, then
> spammers have an incentive to construct fraudulent header elements.    If
> recipients only use this information for blacklisting, then the needs of
> forwarders have not been sufficiently satisfied.
>
> Therefore, I conclude that forwarders will always be dependent on
> recipient organizations who are willing to create local policies to handle
> the traffic from a trusted forwarder differently than traffic from an unrecognized
> forwarder or unforwarded messages from sources with authentication FAIL.
>
>