Upon further reflection, I find myself liking Barry's proposed text less, and instead propose the following:
On Tue, Mar 28, 2023 at 9:42 AM Todd Herr <todd.h...@valimail.com> wrote: > 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. >> > > > To be explicitly clear: domains used for general-purpose email MUST >> > NOT deploy a DMARC policy of p=reject. >> >> > NEW 5.5.6 Decide Whether 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. The policies "reject" and "quarantine" are more effective than "none" for accomplishing the chief goal of DMARC, namely to stop the exact-domain spoofing of the domain in the RFC5322.From header. However, experience has shown that a policy of "reject" can result in the disruption of indirect mail flows and cause damage to the operation of mailing lists and other forwarding services; [@!RFC7960] and [@!RFC8617] and Section 5.8, below, all discuss this topic and/or possible strategies for addressing it. Because of these challenges, some domains, particularly those with open signup capabilities, may prefer to remain at a policy of p=none. This topic is discussed further in section 11.4 below. 11.4 Open Signup Domains and DMARC Policies Certain domains with open signup capabilities, where anyone can register an account and send mail, may not want to implement p=reject. An example of such domains would be consumer mailbox providers that used to be known as "freemail providers". Domains with no DMARC policy or a policy of p=none are vulnerable to spoofing, but their users can send mail using these registered email addresses from unrelated third party systems (such as "forward to a friend" services) or participate in mailing lists without impediment. The security challenges that this presents to the domain owner are left up to those systems that allow open registration of users. -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* todd.h...@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
