Going back through the thread I find more people questioning/disagreeing with the proposed wording than agreeing with it. I don't see a rough consensus.
Michael Hammer On Sat, Apr 8, 2023 at 4:17 PM Scott Kitterman <skl...@kitterman.com> wrote: > We've gone nearly a week without any further discussion on this thread. > > I reviewed the thread and I think this is the closest we got to anything > (most) people agreed on. I know not everyone liked it, but I doubt we're > going to get closer to a consensus on this. > > Can we adopt this and move forward on to the next thing? > > Scott K > > On Wednesday, March 29, 2023 7:42:49 PM EDT Barry Leiba wrote: > > I'm happy with that suggestion. > > > > Barry > > > > On Thu, Mar 30, 2023 at 6:00 AM Scott Kitterman <skl...@kitterman.com> > 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" > <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.iet > > > >f.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. > > > > > > _______________________________________________ > 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
