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

[Barry Leiba <[e-mail]>]

I'm very much against text such as this, as I think it encourages
deployments that are contrary to interoperability and to the intent of
p=reject.

I contend that p=reject (as with the similar construct in the older ADSP)
was intended for high-value domains and transactional mail, and that it was
never intended for use in domains where general users send general email.

I stand by the MUST NOT that I proposed.

Barry


On Wed, Mar 29, 2023 at 10:33 PM Todd Herr <todd.herr=
[e-mail]> wrote:

> 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.
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>