I'm happy with that suggestion. Barry
On Thu, Mar 30, 2023 at 6:00 AM Scott Kitterman <[email protected]> wrote: > > 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" > <[email protected]> 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 <[email protected]> On Behalf Of Barry Leiba > >Sent: Wednesday, March 29, 2023 10:15 AM > >To: Todd Herr <[email protected]> > >Cc: [email protected] > >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 > ><[email protected]<mailto:[email protected]>> > > wrote: > >On Tue, Mar 28, 2023 at 9:06 PM Pete Resnick > ><[email protected]<mailto:[email protected]>> 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: [email protected]<mailto:[email protected]> > >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 > >[email protected]<mailto:[email protected]> > >https://www.ietf.org/mailman/listinfo/dmarc<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dmarc__;!!CQl3mcHX2A!BnSVJ7Ot7xEorNxvwnQPPLKjCUoG0MiUMFnPczO18L4RV-xRev7lnYcl6buwUHNn4JbzvGlzqAMl2J5l4bHsMbKOXw$> > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
