In this discussion about DMARC scoring options
Matt Perry said that he wanted to visit the question of whether SmarterMail should implement support for DMARC Reporting. It seems appropriate to discuss whether this is a development priority for the community (and whether it is an important marketing point for them.)
Sending Reports
To send DMARC Reports, SM will need to be able to build a dataset of all received messages. Once built, this data has lots of potential uses other than DMARC. Effective message review requires the ability to do queries against a dataset of all messages to determine whether blocked messages should have been allowed or allowed messages should have been blocked. But a dataset often implies a database. Adding a database product onto SM involves new resource demands on your server (or a second server), and an additional system administration for managing that database. The reporting process itself will create peak loads once per day. Sending reports as of UTC midnight is recommended. The peak period problem could be solved by sending reports using local midnight as the boundary, or sending reports based as of UTC midnight, but not generated until off-peak hours local time.
The RFC actually specifies two types of reports: Aggregate reports are sent once per day. Forensic reports are sent for every failed message. Forensic reports create a lot of complexity: how to limit the workload and bandwidth that they consume, who should receive the information, what privacy issues might be compromised by them, what can we do to redact messages to reduce privacy concerns, etc. The DMARC specifications are being updated currently and there was strong opinions to drop forensic reports for all of these reasons. People who seem knowledgeable said that forensic reports are usually only sent when there is a contract in place between the sender and receiver. Given all of that, I am assuming that any support for DMARC Reporting in SmarterMail will be limited to aggregate reports.
My own feelings about DMARC reports are tied into my filtering philosophy:
- Authentication is important. I want to know that every received message is properly authenticated, so I apply DMARC authentication to every message.
- Authentication is an imperfect heuristic, so I expect false failures. Therefore, an authentication failure that is not already covered by local policy will be sent to quarantine, not rejected. If it is a wanted message, it will be released from quarantine and local policy updated with alternate authentication.
- If a message is confirmed to be unwanted or malicious, I do not want to provide any information to the sender or attacker. Therefore, I would only send DMARC reports to senders of accepted messages, and those reports should properly indicate that when a DMARC failure was observed, it was overridden. Tracking overrides involves additional data collection and may create dependency on each implementation's spam filtering system.
Receiving and Interpreting Reports
Receiving reports has some technical complexity, but is solvable and I am sure that ST could solve it. Interpreting reports is useful if you are only checking for correct configuration on sending systems. Using reports to detect impersonation is challenging, but I have put some effort into it and have some results:
- 83% of my outbound messages are covered by incoming DMARC reports
- My domains do get impersonated, but not continuously. I am surprised that we get impersonated because we are a one-region business, without any widespread name recognition that I would expect an impersonator to require when choosing an attack strategy.
- DMARC reporting data is cloud-sourced information, and therefore imperfect. Learning the imperfections and working around them is part of the implementation challenge.
So, do we want ST to put development effort into this part of the DMARC RFC?