There is a non-zero set of cases where the IETF prefers security over interoperability. A document like RFC8997/8996 where we've deprecated TLSv1 in because it was no longer secure. I assure you there are still systems/users who have devices incapable of TLSv1.2. DNSSEC (and things that depend on it) can break in "mysterious" ways (specific to DNSSEC) that impact interoperability, but sites do so in the in the name of security.
I think we all understand the inconvenience that DMARC can cause to a subset of domains, or more accurately its users. 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? -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -----Original Message----- > From: dmarc <dmarc-boun...@ietf.org> On Behalf Of Scott Kitterman > Sent: Tuesday, April 11, 2023 11:50 PM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with > p=reject? > > > > On April 12, 2023 3:24:39 AM UTC, Neil Anuskiewicz <neil=40marmot- > tech....@dmarc.ietf.org> wrote: > > > > > >> On Apr 8, 2023, at 6:56 AM, John Levine <jo...@taugh.com> wrote: > >> > >> We're never going to persuade DMARC absolutists that the damage is > >> real, nor the rest of us that we can wave our hands and ignore the damage. > > > >John, the damage is real. There’s no doubt about that. Trade offs, painful > >trade > offs, have to be made and I’m sure this isn’t the first WG to face trade offs > and > have to make hard decisions or not. > > > >If DMARC can protect domains from spoofing which I believe ends up costing > over $14 billion per year. Forget about the $14 billion and think how this > crime > spree affects people’s view of one of the last remnants of the free internet. > It’s > a fiasco on so many levels. If you have the tools to make a real difference > and I > can say from first hand experience DMARC has helped people’s financial and > mental health. > > > >The standard and the document should reflect that it’s already making a > massive difference and could do even more. I don’t think it’s unreasonable to > expect ml managers to adapt. If cyber crime was street crime people would be > panicking in the streets. > > > You can leave the marketing text aside. We know. > > The purpose of IETF specifications is to promote interoperability. For good > reason, they tend to mostly document reality, not drive it. > > The implication of your approach is we punt to experimental because it's > currently impossible to document an interoperable protocol that works for > normal email use cases until the indirect mail flow questions are sorted > (they are > not fully understood yet - ARC is experimental for a reason). Or maybe the > working group just shuts down. > > Alternately we keep this on the standards track with a statement along the > lines > of [some appropriate description] domains MUST NOT publish restrictive > DMARC policies due to interoperability issues. Then the community works on > making it easier for domains not to fit [some appropriate description] so it's > reasonable for them to move to a restrictive policy. > > I believe there's a way to get there on the specifics of the language, if we > work > on it. I have yet to hear any kind of interest in trying to work something > out > from the anti-interoperability crowd. More people showing up to opine about > cyber isn't going to get us there. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;! > !CQl3mcHX2A!GooL5z7r6yyYuhFHHRpgovAgUdqy_1ApVEhmyKC1MGY- > i_qh2X2DY-sNSspGx-Toul9a1rsnu7xwgdQ_V-ZOejFhscE$ _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
