Thanks for that, Scott. For what it’s worth, i have sympathy for your position, both as a participant and as chair. I do, though think that what we have now or something like it is the only way we will get rough consensus, that the other option is not to publish DMARC as a standard, and that given the deployment already the value of publishing the standard with at least this level of warnings overrides the desire to be more strict, knowing that such a greater level of strictness won’t be obeyed.
I wish it weren’t so: I wish that major email platforms would value interoperability over an oddly loose sense of brand protection. But it is so, and they don’t. Barry On Tue, Oct 24, 2023 at 6:07 AM Scott Kitterman <skl...@kitterman.com> wrote: > On Monday, October 23, 2023 4:03:36 AM EDT Francesca Palombini 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/ > > I don't think this is consistent with the IETF's mandate to provide > documents > which promote interoperability. I do not, however, plan to file an appeal > about it. > > Scott K > > > > _______________________________________________ > 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
