On 8/23/25 15:52, Murray S. Kucherawy 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.
Thank you - I think I'm just going to work from the proposed text.
7.2. Report Recipients
...
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.
I have to agree with Mike here re: the "exceed the scope [and] intent"
language - the frequent use of "forensic reports" in earlier documents
was not accidental. During pre- and past-IETF work, the use of failure
reports for threat analysis, etc, was definitely a use case that was
both wanted and used.
As for whether it is still done, I shared on this list in March[1] that
Fortra (I didn't name them at the time) was still directing their
clients to send failure reports to them, and saying that their clients
benefit from this arrangement. I accept that the group may discount or
ignore this, given that Fortra didn't make the time to participate here
and say that for themselves, and other industry participants with
differing opinions on the matter did make the time.
The paragraph really reads like it's more about appropriate uses than
"Report Recipients," though I wouldn't hold the document up over that.
But either way I'd suggest the following.
EXISTING: "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."
SUGGESTED: "Some implementers and consumers of failure reports have used
them for threat identification and mitigation, malware collection, and
other types of analysis. This is still possible, but many have stopped
due to the decline in participating report generators, and the types of
data exposure concerns outlined in the previous section."
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.
I would suggest the following in place of the second sentence.
EXISTING: "In high-volume domains, these reports may propagate large
amounts of spam, phishing messages, or malware samples, inadvertently
increasing the spread of abusive content."
SUGGESTED: "Partially or unredacted reports may propagate large amounts
of spam, phishing, or malware content, all of which may require special
handling by Report Consumers or other recipients to avoid incidents.
This underscores the need to avoid misconfiguration of the destinations
in the "ruf=" reporting URIs, and the suggestions for redaction in this
document. And all of these concerns are heightened for high-volume domains."
And I have no objection to including Mike's suggested mitigation
measures here or elsewhere in the document.
[1] https://mailarchive.ietf.org/arch/msg/dmarc/Z50mslAFMOxmVPImy7EXkuqzpdI/
--S.
_______________________________________________
dmarc mailing list -- dmarc@ietf.org
To unsubscribe send an email to dmarc-le...@ietf.org
