Re: [dmarc-ietf] Sender vs From Addresses

[Douglas Foster]

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

>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Sender vs From Addresses

[Kurt Andersen (b)]

On Wed, Mar 24, 2021 at 3:25 PM Charles Gregory 
wrote:

>
> Has anyone considered an option to add "affiliated domains" to a DNS
> entry?  That way at least you could specify legitimate alternate/authorized
> domains that could still pass DMARC.
>

Yes, but no technically and operationally sound solution has yet achieved
consensus.

--Kurt
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Sender vs From Addresses

[Charles Gregory]

"I talk to people at large mail providers a lot, and I do not recall
this partiticular situation coming up as a problem, ever.  Do you have concrete 
experience to the contrary?"

I am your concrete example.  The users of the custom mail platform I administer 
are a division within a multinational firm.  They are assigned an email 
addresses based on their global domain name and use Office 365.  While 
completely sanctioned, our division's marketing platform doesn't have access to 
the corporate mothership's email infrastructure.  The red tape would be 
prohibitive.  We send our emails from a domain registered for the division on 
behalf of the sending user's corporate email address.  We collect the bounces 
at the division's return path address which is always the same.  The bounces 
are automatically marked and cleaned up in our marketing database.


"The problem with keying DMARC to the sender is that if you believe that people 
look at the From header, it turns DMARC into filtering based on the reputation 
of the DKIM or SPF identity.  Mail providers already knew how to do that before 
DMARC existed."

Has anyone considered an option to add "affiliated domains" to a DNS entry?  
That way at least you could specify legitimate alternate/authorized domains 
that could still pass DMARC.

"other than desktop Outlook, MUAs do not show
the sender at all.  Gmail and web Outlook don't."

I wish they would.

Charles Gregory

Sent from my T-Mobile 4G LTE Device


 Original message 
From: John Levine 
Date: 3/24/21 4:21 PM (GMT-05:00)
To: dmarc@ietf.org
Cc: gell...@mimecast.com
Subject: Re: [dmarc-ietf] Sender vs From Addresses

It appears that Gren Elliot   said:
>For better or worse, there is long established practice in the Calendaring 
>community when implementing iMIP (rfc6047) when an
>assistant is working on behalf of a manager for the manager’s email address to 
>populate the “From:” header and the
>assistant’s email address to populate the “Sender:” header.  Mailing software 
>seems to go to lengths to follow this
>convention even when it doesn’t do so for other email messages “sent on behalf 
>of”.  I assume this means that things will
>break somewhere if this convention isn’t followed for at least some peoples 
>calendaring software.
>
>So, it looks like at the moment people will need to make a choice between 
>enforcing DMARC and having calendaring software continue
>to function.

DMARC only looks at the domain part of the From header.  How often do the 
manager and assistant have e-mail addresses that
are not in the same domain?

>Surely it is possible to offer different levels of DMARC enforcement where 
>there is a level that forces using the “From:”
>header and a newer level which follows the existing email standards for 
>validating who the author is – i.e. use “Sender:” if
>present, else use “From:”?

I talk to people at large mail providers a lot, and I do not recall
this partiticular situation coming up as a problem, ever.  Do you have concrete
experience to the contrary?

The problem with keying DMARC to the sender is that if you believe that people 
look at the From
header, it turns DMARC into filtering based on the reputation of the DKIM or 
SPF identity.  Mail
providers already knew how to do that before DMARC existed.  Noting what Dave 
said, I'm not sure
how closely people look at the From header, but I do know that other than 
desktop Outlook, MUAs do not show
the sender at all.  Gmail and web Outlook don't.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Sender vs From Addresses

[Gren Elliot]

Calconnect’s TC-CALSPAM group is currently looking at this issue and yes, the 
reason is because of real world corporations that use multiple brands with 
different domains.  Typically employees got a single email address on one of 
their domains but often work with people who have email addresses in different 
domains.

From: "Kurt Andersen (b)" 
Date: Wednesday, 24 March 2021 at 20:27
To: John Levine 
Cc: "dmarc@ietf.org" , Gren Elliot 
Subject: Re: [dmarc-ietf] Sender vs From Addresses

On Wed, Mar 24, 2021 at 1:21 PM John Levine 
mailto:jo...@taugh.com>> wrote:
It appears that Gren Elliot  
mailto:gell...@mimecast.com>> said:
>For better or worse, there is long established practice in the Calendaring 
>community when implementing iMIP (rfc6047) when an
>assistant is working on behalf of a manager for the manager’s email address to 
>populate the “From:” header and the
>assistant’s email address to populate the “Sender:” header.

DMARC only looks at the domain part of the From header.  How often do the 
manager and assistant have e-mail addresses that
are not in the same domain?

John,

This goes back to your Roman Empire scenario. It's not necessarily common, but 
it isn't unheard of for domain mismatches especially in the case of 
acquisitions or other corporate structuring changes.

--Kurt
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Sender vs From Addresses

[Kurt Andersen (b)]

On Wed, Mar 24, 2021 at 1:21 PM John Levine  wrote:

> It appears that Gren Elliot   said:
> >For better or worse, there is long established practice in the
> Calendaring community when implementing iMIP (rfc6047) when an
> >assistant is working on behalf of a manager for the manager’s email
> address to populate the “From:” header and the
> >assistant’s email address to populate the “Sender:” header.
>
> DMARC only looks at the domain part of the From header.  How often do the
> manager and assistant have e-mail addresses that
> are not in the same domain?
>

John,

This goes back to your Roman Empire scenario. It's not necessarily common,
but it isn't unheard of for domain mismatches especially in the case of
acquisitions or other corporate structuring changes.

--Kurt
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Sender vs From Addresses

[John Levine]

It appears that Gren Elliot   said:
>For better or worse, there is long established practice in the Calendaring 
>community when implementing iMIP (rfc6047) when an
>assistant is working on behalf of a manager for the manager’s email address to 
>populate the “From:” header and the
>assistant’s email address to populate the “Sender:” header.  Mailing software 
>seems to go to lengths to follow this
>convention even when it doesn’t do so for other email messages “sent on behalf 
>of”.  I assume this means that things will
>break somewhere if this convention isn’t followed for at least some peoples 
>calendaring software.
>
>So, it looks like at the moment people will need to make a choice between 
>enforcing DMARC and having calendaring software continue
>to function.

DMARC only looks at the domain part of the From header.  How often do the 
manager and assistant have e-mail addresses that
are not in the same domain?

>Surely it is possible to offer different levels of DMARC enforcement where 
>there is a level that forces using the “From:”
>header and a newer level which follows the existing email standards for 
>validating who the author is – i.e. use “Sender:” if
>present, else use “From:”?

I talk to people at large mail providers a lot, and I do not recall
this partiticular situation coming up as a problem, ever.  Do you have concrete
experience to the contrary?

The problem with keying DMARC to the sender is that if you believe that people 
look at the From
header, it turns DMARC into filtering based on the reputation of the DKIM or 
SPF identity.  Mail
providers already knew how to do that before DMARC existed.  Noting what Dave 
said, I'm not sure
how closely people look at the From header, but I do know that other than 
desktop Outlook, MUAs do not show
the sender at all.  Gmail and web Outlook don't.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Sender vs From Addresses

[Gren Elliot]

Hi,

For better or worse, there is long established practice in the Calendaring 
community when implementing iMIP (rfc6047) when an assistant is working on 
behalf of a manager for the manager’s email address to populate the “From:” 
header and the assistant’s email address to populate the “Sender:” header.  
Mailing software seems to go to lengths to follow this convention even when it 
doesn’t do so for other email messages “sent on behalf of”.  I assume this 
means that things will break somewhere if this convention isn’t followed for at 
least some peoples calendaring software.

So, it looks like at the moment people will need to make a choice between 
enforcing DMARC and having calendaring software continue to function.

Surely it is possible to offer different levels of DMARC enforcement where 
there is a level that forces using the “From:” header and a newer level which 
follows the existing email standards for validating who the author is – i.e. 
use “Sender:” if present, else use “From:”?

Alternatively, we really ought to update the Email RFCs to deprecate the 
“Sender:” header.  Otherwise you effectively have canonical standards from the 
same standards body which flatly contradict each other.

Software and standards layered on top of email like iMIP would also need 
similar updates.  .  I’m not actually recommending this – whilst we might 
design things differently now, the existing practice with “From:” and “Sender:” 
makes sense to me and the level of complexity with dealing with this seems 
trivial compared to other things we need to deal with.

Regards,
Gren
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Sender vs From Addresses

[Charles Gregory]

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 
(i...@mailprocessingdomain.com) 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 
Date: 3/24/21 1:27 PM (GMT-05:00)
To: Ken O'Driscoll , Charles Gregory 

Cc: IETF DMARC WG 
Subject: Re: [dmarc-ietf] Sender vs From Addresses

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/. That document goes 
into considerable detail on how 5322.Sender could be incorporated in the future.


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
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
Information & PLanning Coordinator
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Sender vs From Addresses

[Hector Santos]

On 3/24/2021 1:26 PM, Dave Crocker wrote:

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/. That 
document goes into considerable detail on how 5322.Sender could be 
incorporated in the future.



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.





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?

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



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Sender vs From Addresses

[Dave Crocker]

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/ 
. That 
document goes into considerable detail on how 5322.Sender could be 
incorporated in the future.



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
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
Information & PLanning Coordinator
American Red Cross
dave.crock...@redcross.org

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Sender vs From Addresses

[Hector Santos]

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  *On Behalf Of *Charles Gregory
*Sent:* Wednesday 24 March 2021 09:49
*To:* dmarc@ietf.org
*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 





1.Why was DMARC designed that way?

·because the people who designed it apparently didn't read section 
3.6.2 of RFC 5322 
, 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 
:


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 

Re: [dmarc-ietf] Sender vs From Addresses

[Dave Crocker]

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
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
Information & PLanning Coordinator
American Red Cross
dave.crock...@redcross.org

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Sender vs From Addresses

[Ken O'Driscoll]

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  On Behalf Of Charles Gregory
Sent: Wednesday 24 March 2021 09:49
To: dmarc@ietf.org
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


1.  Why was DMARC designed that way?
* because the people who designed it apparently didn't read section 
3.6.2 of RFC 5322, 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:

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 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 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 
user@original.domain. 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 

[dmarc-ietf] Sender vs From Addresses

[Charles Gregory]

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


1.   Why was DMARC designed that way?
*   because the people who designed it apparently didn't read section 3.6.2 
of RFC 5322, 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:

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 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 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 
user@original.domain. 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
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc