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= 40valimail....@dmarc.ietf.org> wrote: > On Tue, Mar 28, 2023 at 9:06 PM Pete Resnick <resn...@episteme.net> 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:* todd.h...@valimail.com > *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 > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
