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=40comcast....@dmarc.ietf.org> 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 <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 _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
