I think for interoperability reasons a MUST NOT is the correct decision: Domains that choose to use p=reject and then allow their users to post to mailing lists damage interoperability for uninvolved third parties. However, for rough consensus purposes I would support Barry’s SHOULD NOT language.
laura > On 23 Oct 2023, at 09:03, Francesca Palombini > <francesca.palombini=40ericsson....@dmarc.ietf.org> wrote: > > I have been asked by Murray to assist with a consensus evaluation on the > discussion that has been going on for a while about the dmarcbis document and > how to move forward. > > I have made an attempt to evaluate consensus on the topic, trying to look at > it from a complete outsider’s point of view and trying not to let my personal > opinion bias my assessment. This is a summary of that evaluation. It is based > on several threads in the mailing list: [1], [2], [3] and recordings of the > IETF 117 wg meeting [4]. I also tried to pay attention to chronology of > comments, because some people have expressed different support for different > proposals, in which case I consider the latest email I can find as the > person’s latest opinion. > Although that was mentioned, I believe there is no consensus to move the > document status to Informational. I believe there is a rough consensus that a > change needs to be made in the text to include stronger requirements > admonishing operators against deploying DMARC in a way that causes > disruption. The mails go in many directions, but the most contentious point I > could identify is if there ought to be some normative MUST NOT or SHOULD NOT > text. Many people have suggested text (thank you!). I believe the ones with > more tractions are Scott’s MUST NOT proposal [2] and Barry’s SHOULD NOT > proposal [3]. I believe most people who’d prefer just descriptive text have > stated that they can live with the SHOULD NOT text, but they have stronger > objections towards the MUST NOT text. There also a number of people who > strongly believe MUST NOT is the way to go, but these people have not > objected strongly to Barry’s latest proposed text in the mailing list > (although they have made their preference clear during the meeting [4]). As a > consequence, I believe there is a stronger (very rough) consensus for going > with Barry’s SHOULD NOT text. I also believe there is consensus to add some > non-normative explanatory text (be it in the interoperability or security > consideration sections, or both) around it. > I suggest the authors and the working group start with Berry’s text and > fine-tune the details around it. > In particular, as another AD that might have to ballot on this document, I > suggest that you pay particular attention to the text around the SHOULD NOT, > as also Murray suggested in [5]. I have often blocked documents with the > following text: “If SHOULD is used, then it must be accompanied by at least > one of: (1) A general description of the character of the exceptions and/or > in what areas exceptions are likely to arise. Examples are fine but, except > in plausible and rare cases, not enumerated lists. (2) A statement about what > should be done, or what the considerations are, if the "SHOULD" requirement > is not met. (3) A statement about why it is not a MUST.”. > I appreciate everybody’s patience and constructive discussion. > Francesca, ART AD > [1]: https://mailarchive.ietf.org/arch/msg/dmarc/Z2hoBQLfacWdxALzx4urhKv-Z-Y/ > [2]: https://mailarchive.ietf.org/arch/msg/dmarc/wvuuggXnpT-8sMU49q3Xn9_BjHs/ > [3]: https://mailarchive.ietf.org/arch/msg/dmarc/k6zxrKDepif26uWr0DeNdCK1xx4/ > [4]: https://www.youtube.com/watch?v=8O28ShKGRAU > [5]: https://mailarchive.ietf.org/arch/msg/dmarc/Ld-VObjtihm5uWd9liVzMouQ1sY/ > _______________________________________________ > dmarc mailing list > dmarc@ietf.org <mailto:dmarc@ietf.org> > https://www.ietf.org/mailman/listinfo/dmarc -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
