Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)
updates
- rfc-5965 — An Extensible Format for Email Feedback Reports
Extracted elements (30)
Authentication failure reporting (Section 6) is primarily intended for use during development and debugging of DKIM, ADSP, and SPF, not for prolonged forensic use, due to the load concerns from high-volume automated generation.
MUAs are directed to route abuse reports through their Mailbox Providers rather than sending ARF directly because centralized routing enables aggregate processing, provides training input to filtering systems, and avoids uncoordinated direct contact.
Unsolicited reports in ARF should include all necessary information in the first human-readable text/plain part because some recipients will only be able to access that part; failure to do so may result in the report being discarded or ignored by low-end ticketing systems.
A Feedback Provider sending unsolicited reports SHOULD NOT generate reports for which a reply cannot be received, as no-reply addresses preclude requests for additional information and increase the likelihood that further reports will be discarded.
An automated report processing system MUST NOT reject (in the SMTP sense) a report based solely on an unknown Feedback-Type. Unknown types may be set aside for manual handling.
Automatic authentication failure reports SHOULD use 'Feedback-Type: auth-failure' and SHOULD include Original-Mail-From, Arrival-Date, Source-IP, and Original-Rcpt-To fields when available.
Automatic feedback generators MUST select actual message recipients based on data provided by willing report receivers; recipients MUST NOT be selected using heuristics.
Feedback Providers MUST provide a way for report recipients to request that no further unsolicited reports be sent, though no standardized mechanism currently exists and all existing mechanisms are out-of-band.
Feedback Providers sending unsolicited reports SHOULD send reports that they expect will pass SPF and/or DKIM checks to encourage credibility and response.
Feedback Providers SHOULD NOT report all mail sent from a particular sender merely because some of it is determined to be abusive.
If SPF evaluation of an arriving message produces a 'Fail', 'SoftFail', 'TempError', or 'PermError' result, a report SHOULD NOT be generated to the RFC5321.MailFrom domain, as no reliable assertion can be made that use of the domain was authorized.
If the message under evaluation by the Verifier is itself an ARF message, a report MUST NOT be automatically generated, to prevent feedback loops.
Mailbox Providers SHOULD NOT send solicited reports to addresses that have not explicitly requested them; a valid deviation might result from local policy instructions.
Mechanical reports based solely on inline content analysis tools SHOULD NOT be sent because they are subjective and unlikely to provide a basis for recipient action. Reports from end users or spam traps MAY be sent.
MUAs SHOULD create abuse reports and send them to their Mailbox Providers rather than generating and sending ARF messages directly, to allow centralized processing and filtering system training.
Operators (Feedback Consumers) MUST be able to accept ARF reports as email messages over SMTP. This is a baseline capability requirement for any party participating in a feedback arrangement.
Published abuse mailbox addresses SHOULD NOT reject non-ARF messages based solely on format, as ARF generation can occasionally be unavailable or inapplicable.
Report receivers MUST accept reports that have obscured their user-identifiable data as described in RFC 6590.
Senders of unsolicited reports SHOULD NOT send reports that cannot serve as a basis for action, whether due to non-abuse content, wrong destination address, or unreadable format.
Solicited abuse reports SHOULD use 'Feedback-Type: abuse' and SHOULD include the optional fields Original-Mail-From, Arrival-Date, Source-IP, and Original-Rcpt-To when their values are available.
The envelope sender address of an automatically generated report MUST be chosen to avoid amplification attacks and to ensure no feedback reports will be issued in response; the MAIL FROM command SHOULD use the NULL reverse-path ('MAIL FROM:<>').
Unsolicited reports SHOULD NOT be sent to recipients that are uninvolved or only peripherally involved; they should go to parties both responsible for the messages and able to act on them.
ARF defines two primary feedback types in active use: 'abuse' for reporting unwanted or malicious mail triggered by user action, and 'auth-failure' for automatically generated reports about messages failing authentication checks such as DKIM or SPF.
For unsolicited reports, reasonable candidate destinations include abuse addresses in WHOIS records of the relaying IP address, PTR query results, the abuse@domain role address per RFC 2142, and addresses explicitly described as abuse contacts on a web site.
Recommended optional ARF fields for both solicited and unsolicited reports include: Original-Mail-From (envelope sender), Arrival-Date (receipt timestamp), Source-IP (sending IP address), and Original-Rcpt-To (original recipient). These fields aid automated processing and investigation.
Solicited reports are exchanged under a private bilateral agreement between Feedback Providers and Feedback Consumers, typically triggered by users clicking a 'report spam' button. Unsolicited reports are sent without prior arrangement and have stricter structural and targeting constraints.
ARF reports may be forged as easily as ordinary Internet email. Feedback Providers that relay user complaints directly (rather than by reference to a stored message) could be duped into reporting a message the complaining user never received, enabling attacks on the purported originator. Reports SHOULD themselves be signed with DKIM and/or authorized by SPF.
Failure to use a NULL or carefully chosen envelope sender for automated reports can lead to amplification denial-of-service attacks; an attacker can forge messages that trigger large volumes of reports directed at a victim.
If a host is known to generate reports upon certain incidents, an attacker can forge high volumes of triggering messages to inundate the report recipient. Mitigation includes using ARF's incident count field to batch reports, applying inverse-exponential rate limiting, and halting generation upon temporary failure responses from the destination.
Reports SHOULD NOT be sent to addresses belonging to the abusive parties themselves if they can be identified beforehand, except where the abusive party is known to be responsive, since such reports may reveal information about complainants.