On 28 Mar 2023, at 17:15, Barry Leiba wrote: > 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.
Mailing lists being a primary example of usage that may run afoul of a p=reject policy, but not the only one. > To be explicitly clear: domains used for general-purpose email MUST > NOT deploy a DMARC policy of p=reject. I’m not sure p=quarantine is a good idea either for such domains. > > 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. Strongly agree. The primary problem with DMARC has been the inappropriate use of p=reject policy for domains that aren’t transactional, and clear wording is required to correct that practice. Even for transactional domains, some cautionary text might be added about recipient-side forwarding (alumni domains and the like) that might not be fully transparent and break DKIM signatures. These might also be caught up in a p=reject policy. My college alumni address, which used to be quite transparently forwarded, now breaks the original DKIM signature for reasons that aren’t clear to me. -Jim _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
