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

[Hector Santos <[e-mail]>]

> On Apr 9, 2023, at 2:15 PM, Murray S. Kucherawy <[e-mail]> wrote:
> 
> On Sun, Apr 9, 2023 at 6:33 AM Jesse Thompson <[e-mail] <mailto:[e-mail]>> wrote:
>> 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.
> 
> I don't think the way DMARC has been marketed is germane to discussions about interoperability, which is what "MUST NOT" type language seeks to resolve.

So is that the difference with ADSP and DMARCbis?  Lacking ADSP language to forcibly say ESP-like domains MUST NOT use `DISCARDABLE` policy? DMARCbis will survive this ADSP dilemma by saying MUST NOT p=reject?  👍

Basically what we are authorizing now is permission for MDA, MLS and MTA, middle-ware, to do whatever they need to do that make sure mail is transportable and deliverable, including removing, masking the security wrapper.

Since we will never get this right with this WG and rewrite is the only solution, I now agree to use a MUST NOT. 

So I think it should be outlined what will expected to happen if a domain uses p=reject when they should not:

- risk interop issues,
- messages alterations to remove the DMARC security blanket.

—
HLS