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

[Todd Herr <[e-mail]>]

On Tue, Mar 28, 2023 at 9:06 PM Pete Resnick <[e-mail]> wrote:

> If you agree that interoperability is increased, then I'd suggest that you
> actually do agree that the proposed text is appropriate.
>
>
> I don't know that I agree that interoperability is increased...

I'm having trouble squaring proposed language that says "Domain owners MUST
NOT publish p=reject because it breaks interoperability" with the following
language from section 5.8:

Mail Receivers **MAY** choose to accept email that fails the DMARC

mechanism check even if the published Domain Owner Assessment Policy

is "reject". In particular, because of the considerations discussed

in [@!RFC7960], it is important that Mail Receivers **SHOULD NOT** reject

messages solely because of a published policy of "reject", but that

they apply other knowledge and analysis to avoid situations such as

rejection of legitimate messages sent in ways that DMARC cannot
describe, harm to the operation of mailing lists, and similar.


It seems inconsistent to state with certainty that authorized mail will be
rejected due to authentication breakage when there is no requirement that a
reject policy be honored (and we have plenty of evidence that Mail
Receivers are following the 'SHOULD NOT reject messages' guidance).

Language that would be more consistent in guidance to the domain owners
might look something like this:

After careful analysis of the aggregate report data as described in section
5.5.5

(Collect and Analyze Reports), Domain Owners **MAY** choose to change their
policy from 'none' to 'quarantine' or 'reject'. If, in the Domain
Owner's judgement,

unauthorized and deceptive use of its domain name in the RFC5322.From field
puts

at risk the trust it has built with its recipients, then it is
**RECOMMENDED** that

the Domain Owner make use of the p and/or sp tags to set policy to
'quarantine' or

'reject' for those streams most at risk of loss of trust.


If going that route, probably want to consider expanding on 5.5.5, too; I
need to think about it some more.

-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* [e-mail]
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.