Would you feel any better if the MUST NOT was followed by 'to preserve interoperability '? That's implicitly there and I believe technically correct. If you value other properties of the system higher than interoperability, then the advice may not apply, which is fine.
Scott K On March 29, 2023 3:32:10 PM UTC, "Brotman, Alex" <Alex_Brotman=40comcast....@dmarc.ietf.org> wrote: >I’m just not sure how we determine what is high-value. > >comcast.com: p=reject >comcast.net: p=none >xfinity.com: p=quarantine > >The top one is corporate, middle is consumer, bottom is consumer (but not >actually used) & customer comms (sub-domains). They’re all used in various >ways for internal messaging. Should I tell our corporate admins that they >need to no longer publish p=reject? They’re violating the RFC by doing so? >There are very few consumer-oriented messages that originate from comcast.com. > Are we doing it right? It makes things a little harder when one of our >employees wants to use a mailing list. But that still feels like the right >thing to do. > >If it’s not obvious, I’m having a hard time with “MUST NOT”, and dictating to >domain owners what is in their best interests, regardless of our perceived >value of their domain. > >-- >Alex Brotman >Sr. Engineer, Anti-Abuse & Messaging Policy >Comcast > >From: dmarc <dmarc-boun...@ietf.org> On Behalf Of Barry Leiba >Sent: Wednesday, March 29, 2023 10:15 AM >To: Todd Herr <todd.herr=40valimail....@dmarc.ietf.org> >Cc: dmarc@ietf.org >Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows > >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<mailto:40valimail....@dmarc.ietf.org>> > wrote: >On Tue, Mar 28, 2023 at 9:06 PM Pete Resnick ><resn...@episteme.net<mailto: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<mailto: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<mailto:dmarc@ietf.org> >https://www.ietf.org/mailman/listinfo/dmarc<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dmarc__;!!CQl3mcHX2A!BnSVJ7Ot7xEorNxvwnQPPLKjCUoG0MiUMFnPczO18L4RV-xRev7lnYcl6buwUHNn4JbzvGlzqAMl2J5l4bHsMbKOXw$> _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
