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

["Brotman, Alex" <[e-mail]>]

Should it reference consumer-oriented domains instead? 

Users of comcast.net can't get an email account with out first being an ISP customer.  I don't believe the intent was to exclude them from the proposed language.  Similarly for a few other providers, and then there are explicit pay-for services like Fastmail, Tutanova, etc.  I would think they're in the same category?

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

> -----Original Message-----
> From: dmarc <[e-mail]> On Behalf Of Scott Kitterman
> Sent: Tuesday, March 28, 2023 12:18 PM
> To: [e-mail]
> Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows
> 
> 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
> 
> 
> 
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!
> !CQl3mcHX2A!DOzdiSpU_A-
> KbSj6bpJZO_fnHiQ80eb3LTiQu2G9kcz185A1zp299yH6PyC4_Be61OT86Z4L1fyqtg
> Hk-xPY$