Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Scott Kitterman <[e-mail]>]

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 <[e-mail]> 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