And to add to this, no major mailbox provider sends failure reports, and they have all indicated at M3AAWG and on this list that they will never implement failure reporting.
I’d go further and say that when DMARC was first ideated, there was a belief that failure reports were necessary to understand why mail was failing and how to authenticate it. The past decade has proven this incorrect, as aggregate reports get the job done without the PII risk. No one sends them at scale. Even when you get them, they’re not helpful. They’re an extreme privacy risk and have leaked all sorts of confidential information time and time again. They make it harder to implement DMARC because they add an enormous amount of sifting through the haystack to rarely find useful data. And they violate the private provisions inherent in RFC 6973. Further, the primary use case where failure reports added value has been mitigated with the new tree walk. In larger organization, when the author domain is multiple levels away from the org domain, receiving a report about failing mail isn’t helpful, and failure reports could shine a light on where in the org control lies to fix the problem. This was one of the key operational problems that led us to the tree walk approach. Now with the tree walk, reports can go to the right location and this problem is no longer a big deal like it used to be. For all these reasons and more, I’m strongly in favor of (3). Seth, hatless -mobile On Wed, Mar 19, 2025 at 09:38 Laura Atkins <[email protected]> wrote: > > > On 19 Mar 2025, at 13:12, Todd Herr <[email protected]> > wrote: > > > > On Wed, Mar 19, 2025 at 8:52 AM Mark Alley <mark.alley= > [email protected]> wrote: > >> On 3/19/2025 7:03 AM, Dotzero wrote: >> >> On Wed, Mar 19, 2025 at 7:09 AM Barry Leiba <[email protected]> >> wrote: >> >>> I note that we are shutting down the DMARC working group without >>> completing the failure reporting document. We have discussed what to do >>> about failure reporting,but never made a decision. We need to decide now. >>> >>> I see three options: >>> >>> 1. Continue discussing the document, complete it, and ask Andy to >>> AD-sponsor it. >>> >>> 2. Abandon the document, leave failure reporting as it had been, and >>> refer people to the old (Informational) DMARC spec for documentation of it. >>> >>> 3. Abandon the document and deprecate failure reporting. That would >>> involve mentioning failure reports, noting that they have been seldom used >>> and problematic, and stating that their use going forward is not >>> recommended. >>> >>> I recommend that we do (3), and call for objections to that path. If >>> you agree with (3), please note that here. If you prefer (1) or (2), >>> please state that and say why. If you see another reasonable option and >>> prefer it, please describe it. >>> >>> Please post your opinion by the end of March. >>> >>> I’ll note that options 2 and 3 require adjustments to the approved >>> drafts, and will need Andy’s review and approval for the changes. >>> >>> Barry >>> >>> >> As one of the people who originally came up with DMARC, I strongly >> disagree with approach 3. We could have kept DMARC a "private club" that >> created value only for those invited to participate. Instead the >> participants in the effort felt that the value created should be publicly >> available to everyone through a public standards effort and that IETF was >> the natural place for such an effort. Failure Reports are part of that >> value proposition. They are currently being provided today but >> privately.,as a result of privacy and liability concerns stemming from >> various regulatory frameworks from governmental bodies. >> >> The real question we should be trying to answer is whether or not >> provision of Failure Reports should be kept a public documented standard or >> recede back to a private club monetized by 3rd party intermediaries with no >> hope of it returning to be an open public standard. The question as laid >> out by Barry is strictly procedural without regard to whether there is >> value in keeping Failure Reports a public open standard. I appreciate that >> the DMARCbis effort has been long and arduous. People are tired. If option >> 3 is chosen, Failure Reports won't go away. Their form and function will >> simply become controlled by a handful of large players. There is also the >> risk of divirging format and implementations if individual large players >> look to their own interests. Ultimately, option 3 is a bad choice when >> considering the interests of the community at large and open standards.. >> >> While I prefer option 1, I can reluctantly accept option 2 as it allows " >> a second bite of the apple" at a later point if the IETF email community >> decides to take up the effort at a later point..We are so close. Let's >> complete the journey we started. >> >> Michael Hammer >> >> _____ >> >> +1 to the points and preferences raised here. >> >> >> > I favor option 3, for the following reasons: > > First, it is my belief that failure reports represent an untenable risk of > exposure of PII, especially in the scenario where bad actor A spoofs brand > B in a message to C, where C is not a customer of B and B has no > relationship with C. A failure report sent to B under this circumstance by > C's mailbox provider therefore risks exposing C's PII to B. > > Now, because of the risk of PII exposure, those few providers that still > do send failure reports heavily redact them, which in my view makes them > all but useless for either purpose for which they were originally designed. > They cannot be used for proper troubleshooting of failed authentication of > mail that was authorized by the Domain Owner and they don't provide enough > actionable evidence for any abuse desk or takedown vendor to use to try to > stop fraudulent use of the domain. > > In my opinion, failure reports were a great idea when DMARC was conceived, > but many years of experience should teach us that their time has passed. > > > Agree that option 3 is the right way to go. For all the reasons Todd cited > and the simple fact that folks are simply not sending or consuming failure > reports in any meaningful volume. > > laura > > -- > The Delivery Expert > > Laura Atkins > Word to the Wise > [email protected] > > Delivery hints and commentary: http://wordtothewise.com/blog > > > > > > > _______________________________________________ > dmarc mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
