As noted by Al et al - the forensic reports have a PII problem so sharing them at scale would always be problematic from Google's perspective. So option #3 is my favorite. Technically I'm not against a proposal that includes forensic reports as an option to aggregated reports. I'm just saying those forensic reports would only be shared with a small number of senders and therefor maybe does not make sense as part of DMARC reporting.
Context on PII: My impression is that a lot of senders believe that since they sent the message, they already have the data. I don't think that is the complete picture - the act of reporting an email as spam/phishing is between the recipient and the mailbox provider (unsubscribe is between recipient and sender), hence there is a PII angle. Context on problem to scale: Sharing forensic reports between companies and organizations that have strong relationships and trust makes sense. But if we wanted to have a gate where forensic reports are only shared with "good senders", identifying good senders accurately would be very costly at scale. /E On Thu, Mar 20, 2025 at 9:59 AM Tim Draegen <[email protected]> wrote: > > On Mar 19, 2025, at 7:08 AM, Barry Leiba <[email protected]> > 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 -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
