Subject: Re: [dmarc-ietf] Sender vs From Addresses

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

"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 <[email-masked]>
Date: 3/24/21 4:21 PM (GMT-05:00)
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dmarc-ietf] Sender vs From Addresses

It appears that Gren Elliot  <[email-masked]> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/dmarc

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 24 Mar 2021 15:34:17 -0700

On Wed, Mar 24, 2021 at 3:25 PM Charles Gregory <[email-masked]>
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