On Sat, Aug 23, 2025 at 6:52 PM Murray S. Kucherawy <[email protected]> wrote:
> 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] My first cut at this. Suggested changes and comments in ALL CAPS. 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. NOTE: I ABSOLUTELY DISAGREE THAT THE USE OF DMARC FAILURE REPORTS AS DESCRIBED BELOW IS BEYOND THE SCOPE OF DMARC'S REPORTING INTENT. I WAS THE FIRST PERSON TO PUBLISH A DMARC RECORD, EVEN BEFORE DMARC WAS MADE PUBLIC AND USED THE INFORMATION IN FAILURE REPORTS TO MITIGATE ABUSE IDENTIFIED IN THE REPORTS. IN PROVIDING TRAINING TO HUNDREDS OF PEOPLE THROUGH THE ONLINE TRUST ALLIANCE (NOW PART OF THE INTERNET SOCIETY) I DISCUSSED THESE SORTS OF TECHNIRUES GOING BACK TO 2011. THE STATEMENTS BELOW ARE FACTUAL MISREPRESENTATIONS. THE SECTION BELOW SHOULD BE DROPPED OR DRASTICALLY REWORKED. 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. TO MITIGATE SUCH CONCERNS, THE FOLLOWING STEPS SHOULD BE CONSIDERED: BY REPORT PROVIDERS: *DEFANG URLS BY SUBSTITUTING HXXP FOR HTTP *REMOVE MALICIOUS ATTACHMENTS SUCH AS WORD DOCUMENTS OR PDFs. BY REPORT CONSUMERS: *ISOLATE MX SERVERS RECEIVING REPORTS FROM RECEIVING OTHER MAIL STREAMS *USE SANDBOXES IN EVALUATING FAILURE REPORTS *USE NETWORK SEGMENTATION *LIMIT ACCESS TO FAILURE REPORTS TO AUTHORIZED INDIVIDUALS WITH APPROPRIATE SECURITY TRAINING Michael Hammer
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
