> That's the sort of thing I proposed, and which some participants here are > objecting to. I continue not to understand the objection to clear language > that > says that if you do <this> under <these> conditions, it will cause problems, > so > don't do <this>. I don't buy the idea that saying "don't do <this>" when we > know > that some deployers will ignore that makes us look out of touch with reality, > but > that *not* saying that is better (when that already *has* given DMARC a bad > name in the wider Internet community).
I don’t think folks are objecting to cautionary language. I think folks are objecting to a blanket MUST NOT. If we're going to qualify the MUST NOT with a bunch of language, that's a bit different. The original proposal was: "To be explicitly clear: domains used for general-purpose email MUST NOT deploy a DMARC policy of p=reject." I'm still fuzzy on what constitutes general purpose, or perhaps more accurately when p=reject is acceptable? Is it acceptable to use p=quarantine in those cases? If a domain (such as comcast.com) decides p=reject is what they really want .. then what? (I know, we're not the protocol police..) -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -----Original Message----- > From: Barry Leiba <barryle...@computer.org> > Sent: Thursday, April 13, 2023 12:34 PM > To: Brotman, Alex <alex_brot...@comcast.com> > Cc: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with > p=reject? > > > I think we all understand the inconvenience that DMARC can cause to a > > subset of domains, or more accurately its users. > > The problem here that we're describing as an interoperability issue is not > that > DMARC causes problems for the users of domains that choose to use p=reject -- > that would be the domain's problem -- but that it causes cascading problems > for > the users of *other* domains. That makes it more than an inconvenience. > > > 8996 has a section > > about operational considerations, and discusses the impact of > > systems/users that do not support TLSv1.2 and how it will break > > interoperability. Can we not do similar in DMARCbis with a more > > lengthy section about the implications of "reject"? Perhaps even > > expand it to cover the use cases of each policy type, and the > > implications of each? > > That's the sort of thing I proposed, and which some participants here are > objecting to. I continue not to understand the objection to clear language > that > says that if you do <this> under <these> conditions, it will cause problems, > so > don't do <this>. I don't buy the idea that saying "don't do <this>" when we > know > that some deployers will ignore that makes us look out of touch with reality, > but > that *not* saying that is better (when that already *has* given DMARC a bad > name in the wider Internet community). > > Barry _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
