Dear Alex and all, I appreciate your insights on the challenges of balancing security and interoperability, particularly in the context of DMARC and its implications on email delivery. I agree with your suggestion of adding a more detailed section on the implications of DMARC policies in DMARCbis. We could provide an in-depth explanation of the various policy types, their use cases, and the potential implications of each, which would help stakeholders make more informed decisions when implementing their email authentication strategies.
In light of the ongoing discussion, I would also like to introduce the concept of DSAP (Domain-based Sender Authorization Protocol) with ATPS (Authorized Third-Party Signers) as a potential solution to address these concerns and improve email authentication. DSAP with ATPS aims to offer a more comprehensive and flexible approach to email authentication by accounting for all possible combinations of 1st and 3rd party signers. This not only addresses the limitations of DMARC and its p=reject policy but also enables domain owners to define their own email signature expectations and authorized third-party signers. By adopting DSAP with ATPS, we can reduce false positives and improve the overall accuracy and effectiveness of email authentication, leading to a more secure email ecosystem without causing disruptions to mail delivery. I invite all stakeholders, including MLM developers and operators, to join the discussion and collaborate on the development of DSAP/ATPS as a more robust and adaptable email authentication protocol that serves the interests of all parties involved. I look forward to your thoughts and feedback on this proposal. Best regards, Hector Santos, CEO/CTO Santronics.com > On Apr 12, 2023, at 8:20 AM, Brotman, Alex > <Alex_Brotman=40comcast....@dmarc.ietf.org> wrote: > > 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://www.ietf.org/mailman/listinfo/dmarc
