DMARC is a great step forward for email, as it finally enables us to trust an email’s From address.
Because of the way that most mailing lists are currently implemented, we believe that email receivers who implement DMARC verification (mail hosting companies in particular) should avoid sending forensic DMARC reports (ruf=).
The problem can be replicated by
- Someone requests to have forensic reports sent to their domain (adding DMARC with ruf=)
- He then sends a message to a mailing list
- The message is distributed to all subscribers
- The subscribers’ mail servers might respond with a forensic report
- The report contains the subscriber’s address
This results in information leakage. Lets say somebody is subscribed to a mailing list without participating, believing that his membership isn’t easily disclosed. Therefore, as of today, you probably don’t want to enable the sending of forensic reports when implementing DMARC verification. This is what a forensic report could contain:
Received: from example.com (localhost [127.0.0.1]) by mailinglist.example.com with ESMTP id ... for <SUBSCRIBERS-MAIL-ADDRESS>; Fri, 13 Dec 2013 09:02:45 -0700 (MST)
Are we disclosing a vulnerability? No. The mailing list problem is well understood and discussed by the DMARC community. For example, most DMARC adopters don’t send forensic reports for various reasons. Also, because mailing lists typically violates the DMARC policy, there’s an ongoing effort to change mailing list software so that these issues are resolved. The purpose of this article is simply to raise awareness among potential DMARC adopters, such as mail hosting providers. The concept of forensic reports is powerful, but you need to be aware of this issue.
During some testing that we did, we found a few major hosting companies that did send forensic reports on their user’s behalf, thus leaking information about their users’ mailing list subscriptions.
Anyway, please start using DMARC, for everyone’s sake.
- As for verification and sending reports;
- Everyone should enable DMARC verification
- High volume hosting companies in particular should contribute by sending aggregated reports
- As for signing and receiving reports;
- Most organisations could benefit from activating DMARC in monitoring mode (p=none, rua=mailto:…)
- Organisations which identity is subject to spoofing such as phishing (institutional domains, banks, web services) should enable DMARC fully (p=reject)
- Never-sending domains (which aren’t used to send mail) should enable DMARC (p=reject)
Sending aggregated reports from a Halon system
Building upon our library libdkim++ we had one of the first on-premise e-mail security products with DMARC validation. It’s however important that mail servers (high volume receivers, such as hosting providers, in particular) contribute by sending validation reports.
Instead of re-inventing the wheel, we’ve evaluated OpenDMARC‘s reporting tool. We’ve been using it for some time, and decided to write an integration script which you can download from GitHub. The installation is pretty straight forward by following our guide; which boils down to aggregating logs using remote syslog, and process/report them daily using logrotate.
Why should you start sending reports? Well, first of all it’s one of DMARC’s strengths (which is reflected in in’s name; Domain-based Message Authentication, Reporting and Conformance). For example, reporting is crucial for DMARC’s “monitoring mode”, which is helpful as a first step of deploying DMARC. Further, it enables senders to analyse what’s spoofed in their name. As quoted from dmarc.org;
DMARC addresses these issues, helping email senders and receivers work together to better secure emails, protecting users and brands from painfully costly abuse.
We encourage all our high-volume customers to evaluate DMARC reporting. Feel free to contact us if you have any questions!