Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)
RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties. This applicability statement describes common methods for utilizing this format for reporting both abuse and authentication failure events. Mailbox Providers of any size, mail-sending entities, and end users can use these methods as a basis to create procedures that best suit them. Some related optional mechanisms are also discussed. [STANDARDS-TRACK]
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 10 must, 22 should, 3 may.
4.2 Where to Send Reports
- SHOULD NOTThe Mailbox Provider SHOULD NOT send reports to addresses that have not explicitly requested them.
4.3 What to Put in Reports
- SHOULDThe reports SHOULD use "Feedback-Type: abuse" for the report type.
- SHOULDThe following fields are optional in [RFC5965] but SHOULD be used in this context when their corresponding values are available: Original-Mail-From, Arrival-Date, Source-IP, and Original-Rcpt-To.
- MAYUser-identifiable data MAY be obscured as described in [RFC6590].
4.4 General Considerations for Feedback Consumers
- MUSTOperators MUST be able to accept ARF [RFC5965] reports as email messages [RFC5322] over SMTP [RFC5321].
4.5 What to Expect
- MUST NOTHowever, to allow for handling of new types that are not yet supported, an automated report processing system MUST NOT reject (in the SMTP sense) a report based solely on an unknown Feedback-Type.
- MUSTReport receivers MUST accept reports that have obscured their user- identifiable data as described in [RFC6590].
5.1 General Considerations
- MUSTTherefore, Feedback Providers MUST provide a way for report recipients to request that no further reports be sent.
- SHOULDTherefore, as with any other message, Feedback Providers sending unsolicited reports SHOULD send reports that they expect will pass the Sender Policy Framework (SPF) [RFC4408] and/or DomainKeys Identified Mail (DKIM) [RFC6376] checks.
5.2 When to Generate Reports
- SHOULD NOTSenders of unsolicited reports, especially those sending large volumes of them automatically, SHOULD NOT send reports that cannot be used as a basis for action by the recipient, whether this is due to the report being sent about an incident that is not abuse- related, the report being sent to an email address that won't result in action, or the content or format of the report being hard for the recipient to read or use.
- SHOULD NOTFeedback Providers SHOULD NOT report all mail sent from a particular sender merely because some of it is determined to be abusive.
- SHOULD NOTMechanical reports of mail that "looks like" spam, based solely on the results of inline content analysis tools, SHOULD NOT be sent since, because of their subjective nature, they are unlikely to provide a basis for the recipient to take action.
- MAYComplaints generated by end users about mail that is determined by them to be abusive, or mail delivered to "spam trap" or "honeypot" addresses, are far more likely to be accurate and MAY be sent.
- SHOULD NOTIf a Feedback Provider applies SPF [RFC4408] to arriving messages, a report SHOULD NOT be generated to the RFC5321.MailFrom domain if the SPF evaluation produced a "Fail", "SoftFail", "TempError", or "PermError" report, as no reliable assertion or assumption can be made that use of the domain was authorized.
5.3 Where to Send Reports
- SHOULDRather than generating feedback reports themselves, MUAs SHOULD create abuse reports and send these reports back to their Mailbox Providers so that they can generate and send ARF messages on behalf of end users (see Section 3.2 of [RFC6449]).
- SHOULD NOTFeedback Providers SHOULD NOT send reports to recipients that are uninvolved or only peripherally involved.
- SHOULD NOTFor example, they SHOULD NOT send reports to the operator of every Autonomous System in the path between the apparent originating system and the operator
- SHOULD NOTUnsolicited reports SHOULD NOT be sent to email addresses that are not clearly intended to handle abuse reports.
- SHOULD NOTReports SHOULD NOT be sent to such addresses if they can be identified beforehand, except where the abusive party is known to be responsive to such reports.
5.4 What to Put in Reports
- SHOULDReports SHOULD use "Feedback-Type: abuse" but can use other types as appropriate.
- SHOULDReports SHOULD include the following optional fields whenever their corresponding values are available and applicable to the report: Original-Mail-From, Arrival-Date, Source-IP, and Original-Rcpt-To.
- SHOULDAnyone sending unsolicited reports in ARF can legitimately presume that some recipients will only be able to access the human-readable (first, text/plain) part of it and SHOULD include all information needed also in this part.
- SHOULDFurther, they SHOULD ensure that the report is readable when viewed as plain text, to give low-end ticketing systems as much assistance as possible.
5.5 What to Do with Reports
- MAYPer Section 4.4 of [RFC6449], a network service provider MAY use ARF data for automated forwarding of feedback messages to the originating customer.
- SHOULD NOTPublished abuse mailbox addresses SHOULD NOT reject non-ARF messages based solely on the format, as generation of ARF messages can occasionally be unavailable or not applicable.
- SHOULD NOTThus, a Feedback Provider sending unsolicited reports SHOULD NOT generate reports for which a reply cannot be received.
6 Generating Automatic Authentication Failure Reports
- MUSTAutomatic feedback generators MUST select actual message recipients based on data provided by willing report receivers.
- MUST NOTIn particular, recipients MUST NOT be selected using heuristics.
- MUST NOTIf the message under evaluation by the Verifier is an ARF [RFC5965] message, a report MUST NOT be automatically generated.
- MUSTThe message for a new report sent via SMTP MUST be constructed so as to avoid amplification attacks, deliberate or otherwise.
- MUSTThe envelope sender address of the report MUST be chosen so that these reports will not generate mail loops.
- MUSTSimilar to Section 2 of [RFC3464], the envelope sender address of the report MUST be chosen to ensure that no feedback reports will be issued in response to the report itself.
- SHOULDTherefore, when an SMTP transaction is used to send a report, the MAIL FROM command SHOULD use the NULL reverse-path, i.e., "MAIL FROM:<>".
- SHOULDReports SHOULD use "Feedback-Type: auth-failure" but MAY use other types as appropriate.
- SHOULDThese reports SHOULD include the following fields, although they are optional in [RFC5965], whenever their corresponding values are available: Original-Mail-From, Arrival-Date, Source-IP, and Original-Rcpt-To.