*DMARC Purpose* I have no idea why anti-abuse should be deprecated as a purpose of DMARC. The whole need for authentication derives from the fact that bad actors use fraudulent identifiers. I am already performing abuse takedown based on both incoming messages received and aggregate reports received. If I opted to request failure reports, it would most certainly be for the purpose of anti-abuse takedowns. I support the text of the introduction over the disclaimer added later.
*Privacy - a real world example, from my aggregate reports* I have at least three entities, one government agency and two vendors, that use the following architecture: - My user performs a transaction on the other organization's web server. - The transaction is transmitted from the front-end web server to a back-end transaction server using an email sent with my user's email address. - The transaction server accepts the unauthenticated message because it comes from a trusted server. - The transaction server sends an aggregate report to me that documents their internal communication as an impersonation. I have no idea what information is included in those messages, but if they implement failure reporting as foolishly as they implement aggregate reporting, they could release a lot of information that should at minimum be considered company confidential. Doug Foster On Sat, Aug 23, 2025 at 8:21 PM Dotzero <dotz...@gmail.com> wrote: > > > On Sat, Aug 23, 2025 at 6:52 PM Murray S. Kucherawy <superu...@gmail.com> > 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 -- dmarc@ietf.org >> To unsubscribe send an email to dmarc-le...@ietf.org > > > > 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 -- dmarc@ietf.org > To unsubscribe send an email to dmarc-le...@ietf.org >
_______________________________________________ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
