An Extensible Format for Email Feedback Reports
updated by
- rfc-6650 — Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)
Extracted elements (31)
No empty envelope sender is required for ARF reports (unlike DSN), because an ARF report generating another ARF report in response is considered unlikely. However, using a non-empty envelope sender risks DSN flood attacks if the report is sent to a non-working address.
The format uses IANA registries for extensibility rather than versioning, so version numbers do not change with new field registrations. A new required field, however, requires a new specification version, ensuring parsers can always rely on the core structure.
The specification explicitly does not address where reports should be sent, validation of contents, or how trust is established between report generators and recipients, intentionally leaving these as operational matters expected to be codified in future best-practice documents.
The historic field 'Received-Date' SHOULD be accepted and interpreted identically to 'Arrival-Date' for backward compatibility. However, if both are present simultaneously, the report is malformed and should be handled per Section 4.
Each feedback report MUST be related to only a single email message. Summary and aggregate formats are out of scope for this specification.
Extension report types and header fields MUST be registered via the IANA registries and published in an Open Specification such as an RFC. Experimental types MUST only be used between ADMDs that have explicitly consented to use them.
Feedback report fields SHOULD NOT be repeated as header fields of the enclosing message, as they are semantically distinct from mail message header fields despite similar syntax.
Implementors MUST ignore any fields or report types they do not explicitly support, to encourage extensibility and interoperability.
New field registrations may only be registered as optional fields. Adding a new required field REQUIRES a new version of this specification to be published.
Report receivers MUST NOT assume that assertions in the machine-readable section are always accurate, as these fields represent information the sender is asserting and are not necessarily verifiable.
Report recipients SHOULD use the content of the third part (original message) first for actionable data, then the second part (derived metadata). The first part (human-readable text) SHOULD NOT be used if it conflicts with the other parts.
The first MIME part (human-readable description) and the second MIME part (message/feedback-report) MUST both be included in every feedback report.
The Subject header of the feedback report SHOULD be the same as the included email message. If it differs, the difference MUST be limited to a typical forwarding prefix such as 'FW:'.
The third MIME part containing either the full original message (message/rfc822) or its header block (text/rfc822-headers) MUST be included, contrary to the parent RFC 3462 which makes it optional. It is RECOMMENDED that the entire original message be included without modification to preserve forensic value.
The three required fields Feedback-Type, User-Agent, and Version MUST appear exactly once in the message/feedback-report part. User-Agent format MUST follow HTTP section 14.43; Version is set to '1' for this specification.
When an agent receives a message purporting to be ARF but syntactically deviating from the spec, it SHOULD ignore or reject the message. Rejection notices SHOULD identify the specific cause.
Sending ARF reports can reveal private information about the reporter; for example, a report sent in response to a mailing list posting reveals a valid subscriber address. Report generators may redact portions to conceal private information, though this can impede meaningful forensic response.
An email feedback report is a MIME message with top-level content type 'multipart/report' with the 'report-type' parameter set to 'feedback-report'. It consists of three mandatory parts: a human-readable description, a machine-readable 'message/feedback-report' section, and the original message or its headers.
Optional repeatable fields include: Authentication-Results (auth check outcomes per RFC 5451), Original-Rcpt-To (RCPT TO address, repeated per recipient), Reported-Domain (domain relevant to the report), and Reported-URI (URI relevant to the report, e.g., a suspect link).
Optional single-occurrence fields include: Original-Envelope-Id (SMTP envelope ID), Original-Mail-From (MAIL FROM address), Arrival-Date (formatted per RFC 5322 section 3.3), Reporting-MTA (generating MTA name), Source-IP (IPv4 or IPv6 of sending MTA), and Incidents (unsigned 32-bit integer count of similar incidents).
The 'message/feedback-report' MIME content type contains machine-readable metadata about the report. Its body consists of fields formatted according to the ABNF of RFC 5322 mail header fields, and is semantically distinct from message header fields.
IANA created the 'Feedback Report Header Fields' registry with Specification Required policy. Initial entries include: Arrival-Date, Authentication-Results, Feedback-Type, Incidents, Original-Mail-From, Original-Rcpt-To, Received-Date (historic), Reported-Domain, Reported-URI, Reporting-MTA, Source-IP, User-Agent, and Version.
IANA created the 'Feedback Report Type Values' registry with Specification Required policy. Initial registered types are: 'abuse' (unsolicited email abuse), 'fraud' (phishing/fraud activity), 'other' (miscellaneous feedback), and 'virus' (virus in originating message).
IANA registered the 'message/feedback-report' MIME type. It requires 7bit encoding and applications using it include abuse helpdesk software for ISPs, mail service bureaus, and mail certifiers.
ARF processors SHOULD ensure that attachments are processed as unverified and potentially hostile data, since the format is sometimes used to automatically report malware and the original message may contain active malicious content.
Implementors SHOULD thoroughly verify all ARF messages and be robust against intentionally malformed messages, as attackers may generate extraordinarily large or malformed fields to discover or exploit weaknesses in parsing code.
Systems that automatically generate ARF reports (e.g., honeypot monitors) can be exploited by attackers to flood an ARF recipient with automatically generated reports as a denial-of-service attack.
The authenticity and validity of ARF report content SHOULD be established through other means such as S/MIME, DKIM, SPF, or SenderID before undertaking automated actions. Unvetted reports could contain false, incomplete, or deliberately crafted content intended to trigger undesirable automated responses.
The User-Agent field is trivially forged and SHOULD NOT be interpreted by recipients. It is intended for documentation and debugging only and carries no security significance.
When liberal parsing accepts fields from different versions or transitional states, attackers can craft reports making conflicting claims (e.g., presenting both historic 'Received-Date' and current 'Arrival-Date') to exploit parsing ambiguity. Such choices must be implemented with extreme caution.
The formal ABNF defines feedback-report as: required fields (feedback-type, user-agent, version), opt-fields-once (arrival-date, incidents, original-envelope-id, original-mail-from, reporting-mta, source-ip), opt-fields-many (authres-header, original-rcpt-to, reported-domain, reported-uri), and zero or more ext-field entries. Fields may appear in any order.