As promised, this is what Trent and I propose as a replacement to the current Section 7, to enhance privacy considerations about failure reports based on accumulated experience.
Comments welcome, of course. A diff is not provided as this is a wholesale replacement, though there is clearly some text preserved from the version currently in the datatracker. -MSK 7. Privacy Considerations The generation and transmission of DMARC failure reports (sometimes referred to as "forensic reports") raise significant privacy concerns that must be carefully considered before deployment. Given these factors, many large-scale providers limit or entirely disable the generation of failure reports, preferring to rely on aggregate reports, which provide statistical visibility without exposing sensitive content. Operators that choose to enable failure reporting are strongly encouraged to: * Limit the scope and duration of use to targeted diagnostic activities. * Ensure that reporting URIs are carefully controlled and validated. * Apply minimization techniques, such as redaction of message bodies and header fields, to reduce sensitive data exposure. * Always transmit reports only over secure channels. In summary, while DMARC failure reports can offer diagnostic value, the associated privacy concerns have led many operators to restrict their use. Aggregate reports remain the recommended mechanism for gaining visibility into authentication results while preserving the confidentiality of end-user communications. Particular privacy-specific issues are explored below. 7.1. Data Exposure Considerations Failure reports may include PII and non-public information (NPI) from messages that fail to authenticate, since these reports may contain message content as well as trace header fields. These reports may expose sender and recipient identifiers (e.g. RFC5322.From addresses), and although the [RFC6591] format used for failed-message reporting supports redaction, failed-message reporting is capable of exposing the entire message to the Report Consumer. They may also expose PII, sensitive business data, or other confidential communications to unintended recipients. Such exposure can create regulatory, legal, and operational risks for both senders and receivers. Examples include product launches, termination notices for employees, or calendar data. Even innocuous-seeming failures (such as malformed or “broken” calendar invitations) can result in the leakage of private communications. Domain Owners requesting reports will receive information about mail using their domain, but which they did not actually cause to be sent. This might provide valuable insight into content used in abusive messages, but it might also expose PII or NPI from messages mistakenly or accidentally using the wrong sending domain. Information about the final destination of mail, where it might otherwise be obscured by intermediate systems, may be exposed through a failure report. A commonly cited example is exposure of members of mailing lists when one list member sends messages to the list, and failure reports are generated when that message is delivered to other list members. Those failure reports would be sent to the Domain Owner of the list member posting the message, or their delegated Report Consumer(s). Similarly, when message forwarding arrangements exist, Domain Owners requesting reports may receive information about mail forwarded to domains that were not originally part of their messages' recipient list. This means that destinations previously unknown to the Domain Owner may now become visible. 7.2. Report Recipients A DMARC Policy Record can specify that reports should be sent to a Report Consumer operating on behalf of the Domain Owner. This might be done when the Domain Owner contracts with an entity to monitor mail streams for deliverability, performance issues, or abuse. Receipt of such data by third parties may or may not be permitted by the Mail Receiver's privacy policy, terms of use, et cetera. Domain Owners and Mail Receivers should both review and understand whether their own internal policies constrain the use and transmission of DMARC reporting. Some potential exists for Report Consumers to perform traffic analysis, making it possible to obtain metadata about the Mail Receiver's traffic. In addition to verifying compliance with policies, Mail Receivers need to consider that before sending reports to a third party. Moreover, some implementers and consumers of failure reports have attempted to use them for purposes such as deep threat hunting, malware inspection, or content analysis. While technically feasible, such uses exceed the scope of DMARC’s reporting intent and amplify privacy exposure by treating user communications as telemetry data. DMARC reporting is designed for authentication failure diagnostics, not for generalized message content analysis. Operators have found that misconfigurations of the “ruf=” reporting URI are relatively common, and when they occur, reports may be transmitted to unintended parties. 7.3. Additional Damage The risks associated with failure reports are compounded by volume and content distribution concerns. In high-volume domains, these reports may propagate large amounts of spam, phishing messages, or malware samples, inadvertently increasing the spread of abusive content.
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
