> On Mar 19, 2025, at 7:08 AM, Barry Leiba <barryle...@computer.org> wrote: > > 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.
Hi, I was asked to chime in here. RUF-style reporting was born into a conflicted environment, with A) commercial interests seeing value in the reports to power anti-abuse solutions versus B) using RUF-style reporting to correct authentication problems. The use cases are hugely different. IMO, the commercial interests represented by "A" have dominated discussions with a tragedy-of-commons effect. Those interests want(ed?) RUF-style reporting to become a form of threat feed. If you're lucky enough to get access to the private RUF-style sources, you can differentiate your threat intel / anti-abuse business. RUF-style reporting is only useful in this context if it includes chunks of email content, which runs head on into privacy problems. The tragedy is that commercial interests have said "Dear Internet, please send RUFs to power our threat-feeds"... "Sorry, can't and won't". I am firmly in the "B" camp - even though my own commercial interest is in widespread DMARC adoption. The presence of RUF-style reporting is incredibly helpful in identifying legitimate sources of email that need attention. Unfortunately, working for further adoption of RUF-style reporting is near impossible because "A"-style interests dominate. That said, I cannot support #3 as "seldom used" just isn't true, they're problematic largely in terms of "A" above, and any attempt to make them better would be hindered by "their use going forward is not recommended". I can't get behind #1 mainly because the expertise needed to inform the work isn't here. Murray wrote a bit about creating ways to debug DKIM signatures and seeing almost zero adoption. I read this to mean that this is not the venue where software developers who want to implement new email features live or can work within. I'm in favor of #2.. except leave open an invitation for a different body to refine the work. Bonus points if the decision can include a blurb about "this is not supposed to be used as a channel to transmit threat intel" to give future humans a chance at success. Take care, =- Tim _______________________________________________ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
