I’m a little slow responding to this; my apologies for that. On 23 Oct 2023, at 1:03, Francesca Palombini wrote:
> 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]. Count me in the MUST NOT column, using either Scott’s text or the original text from Barry [1]. The document needs to make a clear statement here, and the text in [3] is far too verbose for most readers to follow, especially when the reasons for not following the SHOULD NOT are added. In addition, [3] seems to presume that the sending domain has some way of knowing what email addresses are mailing lists, and presumes that it knows something about the disposition decision that will be made by the receiving domain (that it does not, in general, even know). Sure, it might determine mailing lists heuristically (looking for mailing list headers on incoming messages, for example), but that won’t work in all cases (alumni addresses being an example). I’m also concerned about p=quarantine: I’m under the impression that address rewriting is done by some mailing lists to avoid the quarantining of mailing list messages. If that is the case, whatever is said about p=reject should also apply to p=quarantine. -Jim _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
