No rehashing, my technical opinion, clearly the semantics but both lead to:
“You SHOULD|MUST consider the documented conflicts before using the restricted policy p=reject” Question. Is p=quarantine ok to use? Or do we presume p=reject implies p=quarantine?’' All the best, Hector Santos > On Feb 29, 2024, at 2:53 PM, Seth Blank <seth=40valimail....@dmarc.ietf.org> > 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 <skl...@kitterman.com > <mailto:skl...@kitterman.com>> 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=40valimail....@dmarc.ietf.org >> <mailto:40valimail....@dmarc.ietf.org>> 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 <skl...@kitterman.com >> ><mailto:skl...@kitterman.com>> >> >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= >> >> 40valimail....@dmarc.ietf.org <mailto:40valimail....@dmarc.ietf.org>> >> >> 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 >> >> dmarc@ietf.org <mailto:dmarc@ietf.org> >> >> https://www.ietf.org/mailman/listinfo/dmarc >> >> >> > >> > >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org <mailto:dmarc@ietf.org> >> https://www.ietf.org/mailman/listinfo/dmarc > > > -- > Seth Blank | Chief Technology Officer > e: s...@valimail.com <mailto:s...@valimail.com> > 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 > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
