Reporting is an important part of DMARC. It provides valuable feedback from mailbox providers to help you identify any problems with authentication of your legitimate emails, and allows you to monitor for fraudulent email misuse of your domain name. But lots of people set up DMARC without understanding the reporting component -- I myself have been guilty of simply routing DMARC reports (which tend to comprise a low volume if emails containing XML-formatted data attachments) to a folder or mailbox to review them "someday." And if that day ever comes, I figure it would be good to understand what I'm looking at as far as the two different types of DMARC reporting -- and why, ultimately, RUA (aggregate) reporting is all I (and you) should rely on.
When creating a "reporting address" for your DMARC record, you might notice that there are two different "reporting" fields in the DMARC record spec:
RUA (aggregate reports) and
RUF (forensic reports).
What data a report contains, how they handle body content, and privacy concerns all vary greatly between the two types of reports.
RUA (aggregate) reports provide the following information:
The domain name in question
The date range
The sending IP address
Whether SPF or DKIM authentication passed or failed
Whether SPF or DKIM authentication aligned with (matched) the from domain
What DMARC policy was applied
What domain was associated with that DKIM or SPF record
To summarize? It's summary data, essentially meant to be rolled up into a tool or dashboard for reporting purposes. And what they don't include is message content. No subject lines, no body content, nothing like that. Just the metadata around the edges, and the domain names used in the visible from header, DKIM header and return-path (SPF) header.
RUF (forensic) reports are a different beast. They can contain full headers – indeed, full message samples, of email messages that failed authentication. Sometimes these will just be phishing or spoofed emails sent by bad guys, and revealing that information in a report isn't intrinsically bad. However, if that message contains personal information of some sort, whoever has access to RUF reporting can end up in possession of PII that was never intended for them. And from talking to various DMARC vendors, I get the impression that RUF reports are more likely to be legitimate mail, not phishing or spoofing.
Not that a DMARC provider has ill intent to review and reveal something private and untoward in a DMARC failed message report, but data privacy laws in various parts of the world are such that many folks think it's best not to risk it. Thus, lots of mailbox providers have stopped sending RUF reports overal – including most US and EU mailbox providers. And if I were building my own tool to receive and parse DMARC reports, I wouldn't even bother with RUF support myself.
I asked Valimail's Todd Herr to double check my assumptions here. Have I gotten it right? What's the actual risk with regard to RUF reporting? He answered: "The thing about personal data and RUF reports is that sometimes the personal data in a RUF report was never in the possession of the recipient of the RUF report until the RUF report was sent.
Example: A sends email to B, spoofing domain C.
B is not a customer of C and has no relationship with C.
B's mailbox provider sends a RUF report to C and has now potentially shared some of B's personal data with C.
"It took me a while to grasp this nuance when DMARC was first introduced. I initially thought RUF reports were ideal troubleshooting tools. If a domain had a mail stream that wasn't authenticating properly, then a full copy of a message failing DMARC would show in the headers which server's configuration was out of whack. It was only when I fully understood the PII risk with the illegitimate messages that the challenges of RUF really sunk in for me."
Thanks, Todd, for helping me understand this a little better! Like him, I originally thought there was more value to RUF reporting, and I didn't quite understand the privacy risks. And whatever my personal opinion might be about those privacy risks, the big mailbox providers tend to feel that RUF risks are too risky to send, so they mostly don't even send them.
Update from Al Iverson, January 29th, 2024: I just wanted to add a clarifying point or two here that I'm not saying that RUF reports are evil or bad or that people who send them or process them are crazy or bad. I had a question -- why do I see so few RUF reports? And when trying to research the answer, I found these various privacy concerns basically explaining why so few ISPs send RUF reports. And so, I was trying to understand why that is, and why they might be concerned about them, and so, for my regular joe use of DMARC reporting, I probably shouldn't expect to see too many of them, so in regular usage, a lot of folks probably don't even need RUF reports to monitor what's up with their domain. I hope that helps to provide a little more detail around why I brought this up and what I was thinking while I wrote it up! And as always, thanks for reading.
Reporting is an important part of DMARC. It provides valuable feedback from mailbox providers to help you identify any problems with authentication of your legitimate emails, and allows you to monitor for fraudulent email misuse of your domain name. But lots of people set up DMARC without understanding the reporting component -- I myself have been guilty of simply routing DMARC reports (which tend to comprise a low volume if emails containing XML-formatted data attachments) to a folder or mailbox to review them "someday." And if that day ever comes, I figure it would be good to understand what I'm looking at as far as the two different types of DMARC reporting -- and why, ultimately, RUA (aggregate) reporting is all I (and you) should rely on.
When creating a "reporting address" for your DMARC record, you might notice that there are two different "reporting" fields in the DMARC record spec:
What data a report contains, how they handle body content, and privacy concerns all vary greatly between the two types of reports.
RUA (aggregate) reports provide the following information:
To summarize? It's summary data, essentially meant to be rolled up into a tool or dashboard for reporting purposes. And what they don't include is message content. No subject lines, no body content, nothing like that. Just the metadata around the edges, and the domain names used in the visible from header, DKIM header and return-path (SPF) header.
RUF (forensic) reports are a different beast. They can contain full headers – indeed, full message samples, of email messages that failed authentication. Sometimes these will just be phishing or spoofed emails sent by bad guys, and revealing that information in a report isn't intrinsically bad. However, if that message contains personal information of some sort, whoever has access to RUF reporting can end up in possession of PII that was never intended for them. And from talking to various DMARC vendors, I get the impression that RUF reports are more likely to be legitimate mail, not phishing or spoofing.
Not that a DMARC provider has ill intent to review and reveal something private and untoward in a DMARC failed message report, but data privacy laws in various parts of the world are such that many folks think it's best not to risk it. Thus, lots of mailbox providers have stopped sending RUF reports overal – including most US and EU mailbox providers. And if I were building my own tool to receive and parse DMARC reports, I wouldn't even bother with RUF support myself.
I asked Valimail's Todd Herr to double check my assumptions here. Have I gotten it right? What's the actual risk with regard to RUF reporting? He answered: "The thing about personal data and RUF reports is that sometimes the personal data in a RUF report was never in the possession of the recipient of the RUF report until the RUF report was sent.
Example: A sends email to B, spoofing domain C.
"It took me a while to grasp this nuance when DMARC was first introduced. I initially thought RUF reports were ideal troubleshooting tools. If a domain had a mail stream that wasn't authenticating properly, then a full copy of a message failing DMARC would show in the headers which server's configuration was out of whack. It was only when I fully understood the PII risk with the illegitimate messages that the challenges of RUF really sunk in for me."
Thanks, Todd, for helping me understand this a little better! Like him, I originally thought there was more value to RUF reporting, and I didn't quite understand the privacy risks. And whatever my personal opinion might be about those privacy risks, the big mailbox providers tend to feel that RUF risks are too risky to send, so they mostly don't even send them.
Update from Al Iverson, January 29th, 2024: I just wanted to add a clarifying point or two here that I'm not saying that RUF reports are evil or bad or that people who send them or process them are crazy or bad. I had a question -- why do I see so few RUF reports? And when trying to research the answer, I found these various privacy concerns basically explaining why so few ISPs send RUF reports. And so, I was trying to understand why that is, and why they might be concerned about them, and so, for my regular joe use of DMARC reporting, I probably shouldn't expect to see too many of them, so in regular usage, a lot of folks probably don't even need RUF reports to monitor what's up with their domain. I hope that helps to provide a little more detail around why I brought this up and what I was thinking while I wrote it up! And as always, thanks for reading.
Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.