Authentication Failure Reporting Using the Abuse Reporting Format
This memo registers an extension report type for the Abuse Reporting Format (ARF), affecting multiple registries, for use in generating receipt-time reports about messages that fail one or more email message authentication checks. [STANDARDS-TRACK]
This document is current and has been amended. 2 later RFCs have changed part of it. Nothing on the RFC itself tells you this.
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 10 must, 3 should, 7 may.
2.3 Base64
- MAYThe values that are base64 encodings MAY contain folding whitespace (FWS) for formatting purposes as per the usual header field wrapping defined in [MAIL].
3 ARF Extension for Authentication Failure Reporting
- MAYMultiple reports MAY be used to report multiple failures for a single message.
3.1 New ARF Feedback Type
- OPTIONALFurthermore, [ARF] specifies this field is OPTIONAL and appears at most once; for this extension, this field MUST be present, but it MUST reflect only a single authentication method's result.
- OPTIONALFurthermore, [ARF] specifies this field is OPTIONAL and appears at most once; for this extension, this field's inclusion is RECOMMENDED, where that value is available, to aid in diagnosing the authentication failure.
- OPTIONALFurthermore, [ARF] specifies this field is OPTIONAL and appears at most once; for this extension, this field MUST be present if such a value is available.
- OPTIONALThis field is OPTIONAL, but it MUST NOT appear more than once.
- SHOULDIf present, it SHOULD indicate the outcome of the message in some meaningful way, but it MAY be set to "other" for local policy reasons.
- MUSTThis part MUST be included (contrary to [REPORT], which makes it optional).
3.2.2 Optional for All Reports
- MUST NOTIt MUST NOT appear more than once.
3.2.4 Optional for DKIM Reports
- MUSTThe encoded content MUST be limited to those octets that contribute to the DKIM body hash (i.e., the value of the "l=" tag; see Section 3.7 of [DKIM]).
- MUST NOTIf DKIM-Canonicalized-Header and DKIM-Canonicalized-Body encode redacted data, they MUST NOT be included.
- SHOULDOtherwise, they SHOULD be included.
3.2.5 Required for ADSP Reports
- MUSTThis MUST be formatted per Section 4.2.1 of [ADSP].
3.2.6 Required for SPF Reports
- MUSTSPF-DNS: This field MUST appear once for every SPF record [SPF] used to obtain the SPF result.
- MUSTIt MUST include the DNS RRTYPE used, the DNS domain from which the record was retrieved, and the content of that record.
3.3 Authentication Failure Types
- MUSTThe DKIM-ADSP-DNS field MUST be included in the report.
- SHOULDThe DKIM-Canonicalized-Body field SHOULD be included in the report (see Section 3.2.4).
- MUSTThe DKIM-Domain and DKIM-Selector fields MUST be included in the report.
- MUSTThe DKIM-Domain and DKIM-Selector fields MUST be included in the report, and the DKIM-Canonicalized-Header field SHOULD be included in the report (see Section 3.2.4).
- MAYSupplementary data MAY be included in the form of comments compliant with [MAIL].