MUST seems to take us back to the unfinished debate of 3 years ago, where some asserted that DMARC did more harm than good and should only be used for transactional mail, which seemed to mean PayPal and not much else.
On Wed, Mar 29, 2023, 6:18 AM Alessandro Vesely <ves...@tana.it> wrote: > On Tue 28/Mar/2023 10:15:04 +0200 Barry Leiba wrote: > > I raised this issue in the DMARC session in Vienna, and have let it > > sit for a while so as not to derail other discussion. As we're pretty > > close to finished with the DMARCbis document, I'd like to raise it > > again, this time with specific proposed text for us to discuss. > > > > And so: > > > > OLD > > > > 5.5.6. Decide If and When to Update DMARC Policy > > > > Once the Domain Owner is satisfied that it is properly authenticating > > all of its mail, then it is time to decide if it is appropriate to > > change the p= value in its DMARC record to p=quarantine or p=reject. > > Depending on its cadence for sending mail, it may take many months of > > consuming DMARC aggregate reports before a Domain Owner reaches the > > point where it is sure that it is properly authenticating all of its > > mail, and the decision on which p= value to use will depend on its > > needs. > > > > NEW > > > > 5.5.6. Decide If and When to Update DMARC Policy > > > > Once the Domain Owner is satisfied that it is properly authenticating > > all of its mail, then it is time to decide if it is appropriate to > > change the p= value in its DMARC record to p=quarantine or p=reject. > > Depending on its cadence for sending mail, it may take many months of > > consuming DMARC aggregate reports before a Domain Owner reaches the > > point where it is sure that it is properly authenticating all of its > > mail, and the decision on which p= value to use will depend on its > > needs. > > > > It is important to understand that many domains may never use > > policies of “quarantine” or “reject”, and that these policies are > > intended not as goals, but as policies available for use when they > > are appropriate. In particular, “reject” is not intended for > > deployment in domains with users who send routine email, and its > > deployment in such domains can disrupt indirect mail flows and cause > > damage to operation of mailing lists and other forwarding services. > > This is discussed in [RFC7960] and in Section 5.8, below. The > > “reject” policy is best reserved for domains that send only > > transactional email that is not intended to be posted to mailing > > lists. > > > > To be explicitly clear: domains used for general-purpose email MUST > > NOT deploy a DMARC policy of p=reject. > > > > END > > > > I'm well aware that the MUST will *not* be followed by everyone, and > > that some domain owners will feel that they need to use p=reject, > > regardless. I think that's fine: the standard should specify what's > > right for interoperability, and I believe that improper use of > > p=reject is extremely harmful to interoperability... so "MUST" is > > correct here. And no one will be arrested or fined for choosing not > > to follow it. We should still say it, nonetheless. > > > I think I grasped Pete's point that MUST is appropriate here even if some > domain owners do otherwise. If we wanted to say "MUST unless" then we > ought to > say SHOULD, but this is not the case. > > General purpose domains, and some well known freemail providers, should > never > have set strict policies. Yet, they did. No clear wording is going to be > able > to correct that practice. Cannot push the genius back into the bottle. > > I'd mention indirect mail flows explicitly, rather than referring to > generic > interoperability problems. But several mailing list adopted expedients in > order to overcome those problems. Furthermore, there are experimental > protocols that address the issue maintaining the end-to-end nature of > existing > identifier fields, and more are going to come. It is possible that a > future > ecosystem will support strict DMARC policies for everyone. Thus it is a > "MUST > until" rather than unless. Is that compliant with RFC 2119? > > > Best > Ale > -- > > > > > > _______________________________________________ > 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
