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

[Scott Kitterman <[e-mail]>]

Technically I think it's domains that send mail which is received via indirect mail flows and want such mail delivered.

I think that's approximately all domains with human users.  The only exception I can think of is if a corporate domain prohibits employees from using their company email address on mailing lists, bug trackers, web forums, etc.

Ultimately I think the conceptual difference is between the view that p=reject being a problem is a special case versus p=reject not being a problem for interoperability is a special case.

I am very much in support of the latter view.

Scott K

On March 28, 2023 4:36:39 PM UTC, "Brotman, Alex" <Alex_Brotman=[e-mail]> wrote:
>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$
>_______________________________________________
>dmarc mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dmarc