An Extensible Format for Email Feedback Reports
This document defines an extensible format and MIME type that may be used by mail operators to report feedback about received email to other parties. This format is intended as a machine-readable replacement for various existing report formats currently used in Internet email. [STANDARDS-TRACK]
This document is current and has been amended. 1 later RFC has 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. 20 must, 16 should, 0 may.
1.1 Purpose
- SHOULD NOTPlease note that while the parent "multipart/report" content type defined in [REPORT] is used for all kinds of administrative messages, this format is intended specifically for communications among providers regarding email abuse and related issues, and SHOULD NOT be used for other reports.
2 Format of Email Feedback Reports
- MUSTThe first MIME part of the message contains a human-readable description of the report and MUST be included.
- MUSTThe second MIME part of the message is a machine-readable section with the content type of "message/feedback-report" (defined later in this memo) and MUST be included.
- MUSTThis part MUST be included (contrary to [REPORT]).
- RECOMMENDEDWhile some operators may choose to modify or redact this portion for privacy or legal reasons, it is RECOMMENDED that the entire original email message be included without any modification as such modifications can impede forensic work by the recipient of this report.
- MUSTExcept as discussed below, each feedback report MUST be related to only a single email message.
- SHOULDThe Subject header field of the feedback report SHOULD be the same as the included email message about which the report is being generated.
- MUSTIf it differs, the difference MUST be limited to only a typical forwarding prefix used by Mail User Agents (MUAs) such as "FW:".
- SHOULDThe second part contains additional derived data that may help the receiver, but in terms of selecting actionable report data, report recipients SHOULD use the content of the third part first, then data from the second part.
- SHOULD NOTThe first part is meant to contain explanatory text for human use but is not itself a part of the report, and SHOULD NOT be used if it is in conflict with the other parts.
3 The 'message/feedback-report' Content Type
- SHOULD NOTAlthough these fields have a syntax similar to those of mail message header fields, they are semantically distinct; hence, they SHOULD NOT be repeated as header fields of the message containing the report.
- MUST NOTReport receivers MUST NOT assume that these assertions are always accurate.
3.1 Required Fields
- MUSTThe following report header fields MUST appear exactly once:
- MUSTThe format of this field MUST follow section 14.43 of [HTTP].
- SHOULD NOTThis field is for documentation only; there is no registry of user agent names or versions, and report receivers SHOULD NOT expect user agent names to belong to a known set.
3.2 Optional Fields Appearing Once
- MUST NOTThe following header fields are optional and MUST NOT appear more than once:
- MUSTThis field MUST be formatted as per section 3.3 of [MAIL].
- MUSTAddresses MUST be formatted as per section 4.1.3 of [SMTP].
- SHOULDThe historic field "Received-Date" SHOULD also be accepted and interpreted identically to "Arrival-Date".
- SHOULDHowever, if both are present, the report is malformed and SHOULD be treated as described in Section 4.
3.3 Optional Fields Appearing Multiple Times
- SHOULDThis field SHOULD be repeated for every SMTP recipient seen by the report generator.
4 Handling Malformed Reports
- SHOULDWhen an agent that accepts and handles ARF messages receives a message that purports (by MIME type) to be an ARF message but syntactically deviates from this specification, that agent SHOULD ignore or reject the message.
- SHOULDWhere rejection is performed, the rejection notice (either via an [SMTP] reply or generation of a [DSN]) SHOULD identify the specific cause for the rejection.
6 Extensibility
- MUSTIn order to encourage extensibility and interoperability of this format, implementors MUST ignore any fields or report types they do not explicitly support.
- MUSTSuch types and fields MUST be registered as described above and published in an Open Specification such as an RFC.
- MUSTExperimental report types and report header fields MUST only be used between ADMDs that have explicitly consented to use them.
7.1 MIME Type Registration of 'message/feedback-report'
- MUSTEncoding considerations: "7bit" encoding is sufficient and MUST be used to maintain readability when viewed by non-MIME mail readers.
- MUSTInteroperability considerations: Implementors MUST ignore any fields they do not support.
7.2 Feedback Report Header Fields
- MUSTNew registrations or updates MUST be published in accordance with the "Specification Required" guidelines as described in [IANA].
- MUSTNew registrations and updates MUST contain the following information:
- MUSTNew or updated status, which MUST be one of:
7.3 Feedback Report Type Values
- MUSTNew registrations MUST contain the following information:
8.2 Interpretation
- SHOULDThe authentication and validity of the content of the report SHOULD be established through other means.
8.4 Intentionally Malformed Reports
- SHOULDImplementors SHOULD thoroughly verify all such messages and be robust against intentionally as well as unintentionally malformed messages.
8.7 Attached Malware
- SHOULDAs this format is sometimes used to automatically report malware, ARF processors (human or otherwise) SHOULD ensure that attachments are processed in a manner appropriate for unverified and potentially hostile data.
8.8 The User-Agent Field
- SHOULD NOTIt is intended for documentation and debugging, and since it is trivially forged by a malicious agent, it SHOULD NOT be interpreted by recipients.