Redaction of Potentially Sensitive Data from Mail Abuse Reports
Extracted elements (18)
No specific transformation algorithm is required because the interoperability goal of this memo is intra-operator correlation, not cross-operator comparison. Consistency of the transformation within a single report generator is what enables correlation; algorithm choice is a local policy decision.
Prior redaction practices replaced local-parts with a uniform string (e.g., "xxxxxxxx"), which prevented any grouping or prioritization of reports. The hash-based approach allows a report receiver to detect that two reports originated from the same end user without revealing that user's identity, enabling prioritization based on repeated offenders.
Strong cryptographic requirements are intentionally omitted because redacted information is ultimately recoverable through log correlation (e.g., via unredacted Message-ID fields). The redaction process satisfies a privacy policy requirement rather than providing a strong security guarantee, so cryptographic strength of the transformation is not a critical security measure.
The ARF specification admonishes generators against overzealous redaction: obscuring too much data renders a report non-actionable. The redaction practice defined here aims to balance user privacy with report utility by obscuring only identified private data fields.
The transformation operates in an environment that is not highly secure; operators must select a transformation resilient to reversal only to the extent required by local policy, rather than assuming the transformation provides absolute protection.
Interoperability in this context means that a single report generator consistently applies the same transformation, allowing the same report receiver to correlate multiple reports from that generator. There is no cross-generator interoperability requirement; two generators may use entirely different transformation algorithms without issue.
Replacing a local-part in an email address with transformation output containing an "@" character (0x40) or space (0x20) is not permitted by the SMTP local-part specification (RFC 5321), so such output must be base64-encoded before substitution to remain syntactically valid.
An implementation MAY choose any transformation mechanism that has a reasonably low likelihood of collision; no specific transformation algorithm is mandated.
If transformation output can contain bytes that are not printable ASCII, or characters inappropriate to replace the private data directly, the output MUST be encoded with base64 (per RFC 4648 Section 4) or a similar translation before substitution.
When redacting reports, the report generator SHOULD use a transformation mechanism that is consistent (same input always produces same output) and reasonably collision-resistant (two different inputs unlikely to produce the same output).
When replacing private data with transformed output, the report generator must observe any contextual constraints on the replacement, such as length limits applicable to the field being replaced.
The redaction method reduces the likelihood of private data leaking between Administrative Management Domains (ADMDs), but report-generation software cannot feasibly identify all the ways private information may be expressed in human-written text. When stronger protections are required, out-of-band arrangements between relevant entities should be established.
A transformation mechanism is any function mapping private data to an obscured output string. Acceptable examples range from trivial encodings (rot13, CRC32, base64) to cryptographic constructs (HMAC-SHA1, full encryption) or internal mappings such as email-address-to-customer-number. The chosen function must be applied consistently across all reports from the same generator.
"Private data" refers to strings within a message (such as local-parts of email addresses) that need to be redacted before a report is shared. Each piece of private data is individually transformed and the original string replaced with the transformation output in the generated report.
The redaction process is a five-step procedure: (1) select a consistent, collision-resistant transformation; (2) identify private data strings; (3) apply the transformation to each; (4) base64-encode if the output is not directly usable in context; (5) substitute each private datum with its (possibly encoded) transformation output when generating the ARF report.
Digest collisions can cause a report receiver to incorrectly conclude that two pieces of redacted information were originally identical when they were not. This can lead to a denial-of-service effect where unjustified corrective action is taken against an innocent party. Such cases are considered sufficiently unlikely to be of little practical concern.
Fields not redacted in the report (such as the Message-ID header) can be correlated against originating system logs or other data sources to recover the original private data. Report generators must anticipate which fields could enable such recovery and redact them as well, or accept that recovery is possible.
The redaction mechanism satisfies a privacy requirement established by local policy and is not designed to provide strong security properties. Bilateral agreements between report producers and consumers (per RFC 6449 and RFC 5965 Section 8) should address the residual information-recovery risks.