I agree that the rough consensus landed on "SHOULD NOT" even though there were some who felt "MUST NOT" was "purer". I was one of those who (reluctantly) supported "SHOULD NOT". Todd is simply trying to get consistency within the document to match the outcome that there was rough agreement on. That is the new issue he is opening and not rehashing the previously closed issue.
Hopefully the chairs will rule on this so we don't have a previous issue reopened during last call. Michael Hammer On Thu, Feb 29, 2024 at 2:53 PM Seth Blank <seth= [email protected]> wrote: > I thought we landed on SHOULD NOT, there was strong resistance to MUST NOT > > On Thu, Feb 29, 2024 at 2:48 PM Scott Kitterman <[email protected]> > wrote: > >> Okay. I think 8.6 is the one in error. You see how this is going to go, >> right? >> >> Scott K >> >> On February 29, 2024 7:45:15 PM UTC, Todd Herr <todd.herr= >> [email protected]> wrote: >> >It is not my intent here to relitigate any issues. >> > >> >Rather, I believe that the text in 7.6 is wrong, likely due to an >> oversight >> >on my part when the new text in 8.6 was published, and I just want to >> >confirm that 7.6 is indeed wrong. >> > >> >On Thu, Feb 29, 2024 at 2:10 PM Scott Kitterman <[email protected]> >> >wrote: >> > >> >> In what way is this a new issue that has not already been argued to >> death >> >> in the WG? I think for WGLC, we've already done this. We will, no >> doubt >> >> get to have this conversation during the IETF last call, but for the >> >> working group, this strikes me as exactly the type of relitigation of >> >> issues we've been counseled to avoid. >> >> >> >> Scott K >> >> >> >> On February 29, 2024 6:54:57 PM UTC, Todd Herr <todd.herr= >> >> [email protected]> wrote: >> >> >Colleagues, >> >> > >> >> >I've been reading DMARCbic rev -30 today with a plan to collect the >> first >> >> >set of minor edits and I came across a sentence that I believe goes >> beyond >> >> >minor, so wanted to get a sanity check. >> >> > >> >> >Section 7.6, Domain Owner Actions, ends with the following sentence: >> >> > >> >> >In particular, this document makes explicit that domains for >> >> >general-purpose email MUST NOT deploy a DMARC policy of p=reject. >> >> > >> >> > >> >> >I don't believe this to be true, however. Rather, Section 8.6, >> >> >Interoperability Considerations, says SHOULD NOT on the topic (e.g., >> "It >> >> is >> >> >therefore critical that domains that host users who might post >> messages to >> >> >mailing lists SHOULD NOT publish p=reject") >> >> > >> >> >Section 7.6 therefore should be updated to read "domains for >> >> >general-purpose email SHOULD NOT deploy a DMARC policy of p=reject", >> yes? >> >> > >> >> >> >> _______________________________________________ >> >> dmarc mailing list >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/dmarc >> >> >> > >> > >> >> _______________________________________________ >> dmarc mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dmarc >> > > > -- > > *Seth Blank * | Chief Technology Officer > *e:* [email protected] > *p:* > > 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] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
