Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?

[Hector Santos <[e-mail]>]

> On Apr 19, 2023, at 10:29 PM, Jesse Thompson <[e-mail]> wrote:
> 
> The choice for both the mailing list and mail-service company is to:
> 
> 1) ignore DMARC and continue to emit mail as the original author intended (the author might be ignorant of DMARC too) and assume the mailbox providers are smart enough to understand that, like mailing lists, mail-service companies and their mail emitting authors shouldn't be caught up by a DMARC misdeployment by the domain owner

This will cause the list bounce problem.  This was seen immediately in the IETF list when it 100% ignorance of DKIM.  Signatures broke.  

Solution: Support DKIM and resign as 3rd party
Problem: Policy does not allow a resigner.

No one honored broken signatures, policies. Recorded as fail but no lost until YAHOO shook the world and began to honor p=reject policies.  Bounce problem.


> 2) be cognisant of DMARC's effects, and in the interest of keeping the author's mail flowing, use a different domain and put the author's address in the friendly from or similar, or just refuse to accept the messages, until delegation can be set up

> I can say, anecdotally, that people really really want #1 to be true, but they eventually learn #2 leads to a better long term outcome. I'd like that "learning" to be less painful by having something unambiguous to point at in DMARCbis.
> 

We allowed a protocol incomplete to take off without dealing with the known potential problem.  No one will honor DKIM policy stuff.

Now its broken.

As a Mailing List Server developer, we need a migration path to a 3rd option (ATPS concept) which using #2 temporarily.   Ideally no From destruction is the goal.  For now, I use #2 restrictions on subscription and submissions 

—
HLS