On Tuesday, March 28, 2023 4:15:04 AM EDT 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. > > OK, have at it.
I think this is pretty good. I would only add a "because ..." clause at the end. Often in IETF documents we say SHOULD/SHOULD NOT unless $REASON if there are clear exceptions. We don't generally justify MUST/MUST NOT because we expect people to adhere to them. In this case though we know that the MUST is going to be met with suspicion is some quarters, so I think we should explain why. It doesn't have to be much. You may have even written it already in your note after the suggested change. I thnk it applies to p=quarantine as well, as Jim Fenton suggested. How about, "... MUST NOT deploy a DMARC policy other than p=none because improper used of p=reject or (to a slightly lesser exent) p=quarantine is extremely harmful to email interoperability." Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
