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

[Mark Alley <[e-mail]>]

I've thought about this a bit more; I could get behind "<general 
purpose> domains MUST NOT publish p=reject" (for interoperability) as 
long as it is made clear the interoperability context for the "MUST NOT" 
does not address the perceived security benefits of its current usage by 
domain owners at large.

As said in your original message that started this topic, "... no one 
will be arrested or fined for choosing not to follow the [MUST NOT]", 
but then I feel like we still have an impasse, because it's not much of 
a standard if nobody adheres to said standard (as others have stated 
on-list), especially so in this case of strict language. The 
recommendation I feel from the community would probably still be, "have 
p=reject as a goal" even with this language in place.

Possibly off-topic slightly, I think BIMI's requirement for DMARC is 
contradictory to what this language is trying to portray for the 
standard. We'd publish "general purpose domains must not publish 
p=reject" for DMARCbis, but then one of the pre-requisites of BIMI is to 
at least have p=quarantine, which still does damage due to the 
non-standardized way disparate receivers handle the policy. Point is, it 
seems conflicting to have two documents telling (and expecting) domain 
owners to do different things.

- Mark Alley

On 4/9/2023 1:33 PM, Barry Leiba wrote:
> > As Todd previously stated, my preference is for language that
> > acknowledges the primacy of the domain owner over interoperability
>
> The problem is that IETF standards are about interoperability, not 
> about anyone’s primacy.
>
> There is an alternative, though: we can acknowledge that because of 
> how those deploying DMARC view their needs over interoperability, 
> DMARC is not appropriate as an IETF standard, and we abandon the 
> effort to make it Proposed Standard.
>
> I see that as the only way forward if we cannot address the damage 
> that improperly deployed DMARC policies do to mailing lists.
>
> Barry
>
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc