Email Feedback Report Type Value: not-spam
Extracted elements (11)
Not-spam reports should not be used as immediate, automatic overrides (e.g., marking all similar messages as good based on a single report). Reports will likely be considered alongside other information and analysis because different users have different views of what constitutes spam, and users sometimes press "report not spam" accidentally.
The feedback types "abuse" and "not-spam" are treated as opposites: a mistaken not-spam report can be countermanded by a subsequent abuse report from the same user, and operators may consider collected reports of both types when making future assessments.
The requirement for a not-spam report type originated from the Open Mobile Alliance (OMA) Spam Report Requirement Document. Existing anti-spam systems already use non-standard "not spam" feedback, mixing reports with other data and algorithms rather than treating any single report as authoritative.
The "not-spam" feedback type extends the Email Feedback Reports specification defined in RFC 5965. Implementations must conform to the ARF base format defined there, including use of DKIM signing (as suggested in RFC 5965 Section 8.2) for report authenticity.
The not-spam report type is registered in the IANA "Feedback Report Type Values" registry according to the instructions in Section 7.3 of RFC 5965, establishing the formal mechanism for extending ARF with new report types.
In the first MIME part of the not-spam feedback report, the end user or email client MAY add free-text information explaining why the message is not considered spam — for example, because the originator or its domain is well known.
This document defines a new ARF feedback report type value, "not-spam", extending RFC 5965. It is used to report an email message that was mistakenly marked as spam by a filtering system or user.
IANA has registered the new feedback type name "not-spam" in the "Feedback Report Type Values" registry per RFC 5965 Section 7.3. The description states: indicates the entity providing the report does not consider the message spam, and may correct a message incorrectly tagged.
All security considerations from RFC 5965 are inherited. Additionally, not-spam reports are likely to be used in attacks on filtering systems by reporting true spam as not-spam. Operators must be careful in trusting such reports beyond their applicability to the specific reporting user.
Even absent malice, some not-spam reports may be made in error or may only apply to the individual user sending the report, not to other users. Operators should not apply not-spam reports universally.
A not-spam report is a multipart/report message with Content-Type report-type=feedback-report. The second MIME part contains a message/feedback-report body with the field "Feedback-Type: not-spam". The original message is included as a third MIME part with Content-Type message/rfc822.