On Tuesday, March 28, 2023 11:58:40 AM EDT Todd Herr wrote: > 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.
I don't understand the connection between DMARC policies and open signup domains? What makes them in any way special relative to DMARC? Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
