Authentication Failure Reporting Using the Abuse Reporting Format
updated by
Extracted elements (27)
A single auth-failure report covers only one authentication method failure. Multiple reports are required to convey multiple failures for a single message. This one-failure-per-report design keeps the Authentication-Results field (which must reflect a single method) unambiguous and simplifies automated parsing.
Base64-encoded values in ARF header fields MAY contain folding whitespace (FWS) for formatting purposes per standard header field wrapping; during decoding, any non-base64 characters are ignored, so line wrapping does not corrupt the encoded value.
The DKIM canonicalized header and body fields are intended to aid in identifying message alterations that invalidate DKIM signatures in transit; their data must exactly match the verifier's computation. Including redacted versions would render the fields useless for this diagnostic purpose, so they are excluded entirely when redaction is needed rather than included in redacted form.
The 'spf' auth-failure type covers SPF results of 'none', 'fail', 'softfail', 'temperror', or 'permerror'. 'none' is not strictly a failure per RFC 4408 (SPF), but a service requiring successful SPF evaluations may treat it as a failure for reporting purposes.
This extension overrides several base ARF field requirements: Authentication-Results (OPTIONAL in ARF) becomes MUST; the third MIME part (optional in the multipart/report base spec) becomes MUST; and Reported-Domain (OPTIONAL in ARF) becomes MUST when the value is available.
For 'adsp' failure type, the DKIM-ADSP-DNS field MUST be included. For 'revoked' and 'signature' failure types, DKIM-Domain and DKIM-Selector MUST be included. For 'signature', DKIM-Canonicalized-Header SHOULD also be included.
For the 'auth-failure' feedback type, the Authentication-Results header field MUST be present in the second (machine-parseable) MIME part of the report, and it MUST reflect only a single authentication method's result.
If DKIM-Canonicalized-Header or DKIM-Canonicalized-Body would encode redacted data, they MUST NOT be included; otherwise they SHOULD be included, and the data presented MUST be exactly the canonicalized header and body as computed at the verifier.
The Original-Envelope-Id, Original-Mail-From, and Source-IP fields are RECOMMENDED in auth-failure reports where those values are available, to aid in diagnosing the authentication failure.
The Reported-Domain header field MUST be present in an auth-failure report if a reported domain value is available.
The third MIME part of an auth-failure report (containing the original message header block, as message/rfc822 or text/rfc822-headers) MUST be included, contrary to the base REPORT spec which makes it optional.
A new ARF feedback type 'auth-failure' is defined as an extension to ARF (RFC 5965) for reporting email authentication method failures at receipt time. A single report describes a single authentication failure; multiple reports MAY be used for multiple failures on one message.
Auth-Failure is a new required ARF header field (for all auth-failure reports) that indicates the specific email authentication method failure type being reported. Valid values are: adsp, bodyhash, revoked, signature, spf.
Delivery-Result is an optional ARF header field indicating the final message disposition (delivered, spam, policy, reject, other). It MUST NOT appear more than once and applies to all auth-failure reports.
DKIM-ADSP-DNS is required for ADSP failure reports and MUST be formatted per Section 4.2.1 of RFC 5617 (ADSP), including the retrieved Author Domain Signing Practices policy record.
Five authentication failure types are defined for the Auth-Failure field: 'adsp' (ADSP signing practice violation), 'bodyhash' (body hash mismatch), 'revoked' (DKIM key revoked), 'signature' (DKIM signature verification failure), and 'spf' (SPF result of none/fail/softfail/temperror/permerror).
SPF-DNS is required for SPF failure reports and MUST appear once per SPF record used; it MUST include the DNS RRTYPE, the domain from which the record was retrieved, and the record content.
Three header fields are required for DKIM failure reports: DKIM-Domain (from the 'd=' tag), DKIM-Identity (from the 'i=' tag), and DKIM-Selector (from the 's=' tag) of the failed DKIM signature.
Two optional DKIM fields carry forensic data: DKIM-Canonicalized-Header (base64-encoded canonicalized header as computed by the verifier) and DKIM-Canonicalized-Body (base64-encoded canonicalized body, limited to octets contributing to the DKIM body hash per the 'l=' tag).
The ARF Feedback Report Header Fields registry is updated with ten new fields: Auth-Failure, Delivery-Result, DKIM-ADSP-DNS, DKIM-Canonicalized-Body, DKIM-Canonicalized-Header, DKIM-Domain, DKIM-Identity, DKIM-Selector, DKIM-Selector-DNS, and SPF-DNS, all with Multiple Appearances: No and Related Feedback-Type: auth-failure.
The ARF Feedback Report Type Values registry is updated with feedback type 'auth-failure' (description: email authentication failure report, published in RFC 6591, status: current).
Auth-failure reports can be forged as easily as ordinary Internet email. Threats include falsified authentication failure notifications for messages that were actually delivered, and falsified DKIM signature metadata (selector, domain, etc.). Signing reports with DKIM is suggested as mitigation, though DKIM infrastructure failures at the verifier could render such signatures untrusted.
Automatic generation of auth-failure reports can create a denial-of-service attack when large volumes of email trigger authentication failures. Report generators SHOULD only generate reports after an out-of-band arrangement between parties, rather than triggering automatically based on DNS-discovered data alone.
DKIM canonicalized header and body data must not be redacted when included, because redacting overlapping regions with any in-transit alteration renders the debugging comparison meaningless. This creates a privacy tension: unredacted canonicalized data may expose private information, which is why including these fields is not required.
Reporting multiple incidents can be exploited: an attacker forging high volumes of triggering messages can flood the report recipient. Mitigation strategies include periodic batching (e.g., inverse-exponential reporting: first 10, then every 10th up to 100, then every 100th up to 1000), at the cost of per-incident detail.
Auth-Failure field: 'Auth-Failure:' followed by one of 'adsp', 'bodyhash', 'revoked', 'signature', 'spf', with optional CFWS. SPF-DNS field encodes DNS RRTYPE ('txt' or 'spf'), domain, and quoted-string record value separated by colons.
DKIM-Identity is encoded as 'DKIM-Identity:' followed by an optional local-part, '@', and domain-name (CFWS-separated), where local-part is per RFC 5322 and domain-name per RFC 6376.