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 <dmarc-boun...@ietf.org> On Behalf Of Scott Kitterman > Sent: Tuesday, March 28, 2023 12:18 PM > To: dmarc@ietf.org > 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 <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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;! > !CQl3mcHX2A!DOzdiSpU_A- > KbSj6bpJZO_fnHiQ80eb3LTiQu2G9kcz185A1zp299yH6PyC4_Be61OT86Z4L1fyqtg > Hk-xPY$ _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
