My opinion is that Barry's text is good as is. As far as delimiting a SHOULD
NOT with another SHOULD is legit, this sentence sounds clear to me:
It is therefore critical that domains that host users who might
post messages to mailing lists SHOULD NOT publish p=reject. Domains
that choose to publish p=reject SHOULD implement policies that
their users not post to Internet mailing lists.
The exceptions to the latter SHOULD are rather obvious. Do we really need to
formally specify domain policing?
My perception is that Section 8.6 puts the issue in very clear terms. It is
even overly clearly and thoroughly explained for average readers. Only IETF
purists longing for email as it was in the 80s consider it important to point
out how DMARC is unjustly oppressing email forwarding, including mailing lists.
The rest of the world just use it as needed. In today's reality, we should
just move forward, and devise further protocols to fix forwarding after
DMARCbis is out.
By contrast, the last paragraph of Section 7.6 contradict this point and should
be removed.
Best
Ale
On Mon 23/Oct/2023 10:03:36 +0200 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/
<https://mailarchive.ietf.org/arch/msg/dmarc/Z2hoBQLfacWdxALzx4urhKv-Z-Y/>
[2]: https://mailarchive.ietf.org/arch/msg/dmarc/wvuuggXnpT-8sMU49q3Xn9_BjHs/
<https://mailarchive.ietf.org/arch/msg/dmarc/wvuuggXnpT-8sMU49q3Xn9_BjHs/>
[3]: https://mailarchive.ietf.org/arch/msg/dmarc/k6zxrKDepif26uWr0DeNdCK1xx4/
<https://mailarchive.ietf.org/arch/msg/dmarc/k6zxrKDepif26uWr0DeNdCK1xx4/>
[4]: https://www.youtube.com/watch?v=8O28ShKGRAU
<https://www.youtube.com/watch?v=8O28ShKGRAU>
[5]: https://mailarchive.ietf.org/arch/msg/dmarc/Ld-VObjtihm5uWd9liVzMouQ1sY/
<https://mailarchive.ietf.org/arch/msg/dmarc/Ld-VObjtihm5uWd9liVzMouQ1sY/>
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
