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

[Jesse Thompson <[e-mail]>]

On Sat, Apr 8, 2023, at 8:17 PM, Mark Alley wrote:
> Personally, I prefer the latter of the two, quoted below.
> 
> "to preserve interoperability, domains SHOULD NOT publish p=reject unless they are [not general purpose]* domains"
> 
> "Publishing DMARC records with restrictive policies does cause interoperability problems for some normal email usage patterns. Potential impacts MUST be considered before any domain publishes a restrictive policy."

I like the latter, as well. I was going to suggest something similar.

As Todd previously stated, my preference is for language that acknowledges the primacy of the domain owner over interoperability. CISOs have been sold (arguably, by the DMARC deployment companies' marketing) on the idea that there are security benefits. Maybe oversold, but there are benefits and the motivation will not change. Let's not also overlook the primary benefit of _the process of deploying DMARC_ gives to an organization: increased management and governance (enabled by the observability from the reports). In any case, the domain owner is motivated to deploy DMARC and gain the perceived benefits. If we are going to tell these motivated domain owners to MUST do something, at least make it something they might consider doing.

"Before a general purpose domain publishes p=reject|quarantine, the domain owner MUST emit mail from, or provide to their stakeholders/end-users, an alternative domain or subdomain with a p=none policy for any email that needs to traverse a non-DMARC-mitigating MLM or (more generally) from any 3rd party that cannot be authorized by SPF or DKIM alignment."

That, combined with Mark's language, I think would resonate with domain owners more than MUST NOT p=reject.

Jesse