Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Alessandro Vesely <[e-mail]>]

On Sun 09/Apr/2023 09:50:46 +0200 Murray S. Kucherawy wrote:
> Mike Hammer asks, reasonably, whether an IETF standard containing a "MUST NOT" 
> that we know people will ignore calls into question the IETFs relevance or 
> legitimacy.  But I submit that the IETF issuing a standards track document 
> which fails to take the strongest possible stance against deploying DMARC in a 
> way that knowingly imposes substantial breakage, for any reason, is 
> irresponsible and is the greater threat to our legitimacy.  Keep in mind that 
> improper deployment of DMARC results in damage to innocent third parties: It's 
> not the sender or the MLM that's impacted, it's everyone else on the list.  
> It's breathtaking to me that we can feel comfortable shrugging this off under 
> the banner of "security" or "brand protection".


It is not clear whether the damage is caused by those who publish p=reject 
rather than by those who honor it.  For the protocol to work, both are needed.

History ratified that mailing lists are the refractory element.  At the time, 
John compiled a list of possible DMARC workarounds[*].  Out of inertia, From: 
rewriting emerged as the de-facto standard.  It works.  It's amendable, though; 
there are cooperative solutions for example.  And ARC.

Rather than considering how to better the coordination between senders and 
receivers, we disregard the mailing lists adaptation as undue.  Thus we're 
stuck at crossroads.  DMARC breaks mailing lists.  SPF breaks forwarding.

For a possible way forward, senders can coordinate with receivers by 
identifying mail streams, pivoting on users who subscribe to mailing lists or 
require forwarding for email address portability.  Just like the classic, 
one-sided whitelisting of specific email addresses, but using email authentication.

Can we stop longing for the 1980s?  Let's accept the damaged we caused.  It's 
been mended already.


Best
Ale
-- 

[*] https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail