> On Apr 8, 2023, at 3:28 PM, Scott Kitterman <skl...@kitterman.com> wrote: > > There are several variations of text that roughly mean the same thing, > particularly when you keep in mind that IETF specifications are intended to > be > interoperability specifications, not implementation specifications. > > We could do I think any of the following and they are roughly semantically > equivalent: > > [general purpose]* domains MUST NOT publish p=reject to preserve > interoperability > > to preserve interoperability, domains SHOULD NOT publish p=reject unless they > are [not general purpose]* domains > > which could be accompanied by: > > [not general purpose]* domains SHOULD determine their email authentication > deployment is accurate and complete before publishing restrictive policies > (p=quarntine or p=reject) to avoid interoperability issues. > > Publishing DMARC records with restrictive policies does cause > interoperability > problems for some normal email usage patterns. Potential impacts MUST be > considered before any domain publishes a restrictive policy. > > * whatever the right formulation is, that's a related, but distinct (and I > think less controversial question). > > I think there's enough there for everyone to find their preferred answer. I > think it's clear on the interoperability risks, but the last MUST allows for > the realist case that people are going to do it anyway. I have no preference > between the first two alternatives. > > > >> On Saturday, April 8, 2023 5:12:56 PM EDT Mark Alley wrote: >> Re-looking at the definition of "SHOULD NOT", I don't see why it can't >> be considered. >> >> "SHOULD NOT - This phrase, or the phrase "NOT RECOMMENDED" mean that >> there may exist valid reasons in particular circumstances when the >> particular behavior is acceptable or even useful, but the full >> implications should be understood and the case carefully weighed before >> implementing any behavior described with this label." >> >> Seems to fit perfectly with how domain owners currently can pick and >> choose interoperability with p=none over more strict protection, or vice >> versa with p=reject, in my opinion. Is that not considered "acceptable" >> by this definition's context? >> >>> On 4/8/2023 4:10 PM, Scott Kitterman wrote: >>> Possible. I didn't count. >>> >>> I didn't see any convergence towards an alternative. >>> >>> I think adding explicitly that the MUST is related to interoperability >>> reasonably addresses the concern that there are non-interoperability >>> reasons people are going to publish p=reject despite the side effects. >>> >>> I don't see a stronger consensus for a specific alternative. >>> >>> I think we have exhausted the discussion on the topic, so, whatever the >>> resolution, I'd like to see the chairs drive the question to closure. >>> It's pretty clear it's not going to naturally drift into a universal >>> consensus. >>> >>> Scott K >>> >>> On April 8, 2023 8:58:13 PM UTC, Dotzero<dotz...@gmail.com> wrote: >>>> 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
Yes, I think so. I get the feeling you possibly think it’s text that isn’t going to make much of an impact but presumably it’ll at least make a difference at the margins? The margins can grow as others see the benefits. I don’t know. Neil _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
