RFC 6430

Email Feedback Report Type Value: not-spam

📅 published November 2011, from ietf

RFC 6430 💖 Email Feedback Report Type Value: not-spam

Okay bestie, the title block is giving main character 👑. This is RFC 6430, called "Email Feedback Report Type Value: not-spam" 🦋. It comes from the IETF (Internet Engineering Task Force) and is a Standards Track document ✨, published in November 2011 🌸. The authors are Kepeng Li (K. Li) and Barry Leiba (B. Leiba), both at Huawei Technologies 💅. The ISSN is 2070-1721 🎀. The title block has no Obsoletes or Updates line, so it doesn't list any older RFC it replaces or changes 🙈.

Abstract

Okay so this doc adds a brand new feedback report type value to the Abuse Reporting Format (ARF) called "not-spam" 🧚. It's for reporting an email message that somebody accidentally marked as spam, which is so relatable 😭.

Status of This Memo 📜

This is an Internet Standards Track document 🔥.

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 💜. If you want more info on Internet Standards, check out Section 2 of RFC 5741 🌈.

For the current status, any errata, and how to give feedback on this doc, go to http://www.rfc-editor.org/info/rfc6430 ⭐.

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved ✨.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date 📖. Please read these carefully, because they spell out your rights and restrictions for this doc 🙏. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 💅.

Table of Contents 🗂️

   1. Introduction ....................................................2
      1.1. Discussion .................................................2
   2. Feedback Report Type: not-spam ..................................3
   3. Example .........................................................3
   4. Security Considerations .........................................5
   5. IANA Considerations .............................................6
   6. Acknowledgements ................................................6
   7. References ......................................................6
      7.1. Normative References .......................................6
      7.2. Informative References .....................................6

1. Introduction ✨

Okay so RFC 5965 [RFC5965] defines the Abuse Reporting Format (ARF) for reporting email abuse 🦋. Right now there are two feedback report types for spam-related problems that can be used to report abusive or fraudulent emails 💀:

  • abuse: means unsolicited email or some other kind of email abuse 🙈.
  • fraud: means some kind of fraud or phishing activity 😬.

This spec adds a new feedback report type called "not-spam" 🌸. You can use it to report a message that got mistakenly marked as spam 🫶.

1.1. Discussion 💬

Sometimes an email client gets a message that was wrongly tagged as spam, either by the email system or because the user accidentally hit the button 🙃. The email client takes the end user's "not-spam" instruction, grabs info about the message, and reports it as not-spam to the email operator 📨. Once the operator gets the report, it can figure out what to do for that particular message and user 💅. (The need for a not-spam report type came from the Open Mobile Alliance (OMA) Spam Report Requirement Document [OMA-SpamRep-RD] 🧚.)

For example, after a "not-spam" report, the email system can remove the spam tag or reclassify the message, which might stop similar emails from getting marked as spam for this user later 🎀. The report can also help train an automated classifier 🤖. After processing the report, the operator might tell the email client how it went, like by moving the message from "Junk" to "Inbox" 📬.

Most of the time, "not-spam" reports won't stand alone 😤. They get looked at alongside other info, analysis of the message, and so on 🔍. Different users have different needs and different ideas of what counts as spam, so a report from one user might or might not apply to someone else 🌈. And since people sometimes hit "report not spam" by accident, instant strong action, like marking every similar message as "good" based on one report, probably isn't the right move 🙅‍♀️. Recipients of "not-spam" reports need to think about what's right for their own setups 💜.

Some anti-spam systems already use (non-standard) "not spam" feedback 👀. All of them mix those reports with other spam reports and data, using their own algorithms, to decide what to do ✨. None of the existing systems use a "not spam" report as an immediate, automatic override 🙌.

The feedback types "abuse" and "not-spam" are kind of opposites ☯️. A mistaken "not-spam" report could be countered by a later "abuse" report from the same user, and an operator could look at the collected "abuse" and "not-spam" reports when making future calls 💖.

2. Feedback Report Type: not-spam 🎀

This doc defines the new feedback report type "not-spam", which extends the Email Feedback Reports specification [RFC5965] 🦋.

In the first MIME part of the feedback report message, the end user or the email client can add info explaining why the message isn't spam, for example because the originator or its domain is well known 🌸.

3. Example 🧚

In this example, Joe is a pharmaceuticals sales rep who got a message about discount pharmaceuticals 💊. That's a super common spam topic, so the message got marked as spam, but wrongly this time 😭. Joe reported it as "not-spam". Below is that report, shortened with the "[...etc...]" part so it fits here ✂️.

Heads up: the message is signed with DomainKeys Identified Mail (DKIM) [RFC6376], which is a good security practice, as Section 8.2 of RFC 5965 [RFC5965] suggests 🔐.

   DKIM-Signature: v=1; a=rsa-sha256; s=abuse; d=example.com;
     c=simple/simple; q=dns/txt; i=abusedesk@example.com;
     h=From:Date:Subject:To:Message-ID:MIME-Version:Content-Type;
     bh=iF4dMNYs/KepE0HuwfukJCDyjkduUzZFiaHqO9DMIPU=;
     b=e+BF8DCHFGqCp7/pExleNz7pVaLEoT+uWj/8H9DoZpxFI1vNnCTDu14w5v
       ze4mqJkldudVI0JspsYHTYeomhPklCV4F95GfwpM5W+ziUOv7AySTfygPW
       EerczqZwAK88//oaYCFXq3XV9T/z+zlLp3rrirKGmCMCPPcbdSGv/Eg=
   From: <abusedesk@example.com>
   Date: Thu, 8 Mar 2005 17:40:36 EDT
   Subject: FW: Discount on pharmaceuticals
   To: <abuse@example.net>
   Message-ID: <20030712040037.46341.5F8J@example.com>
   MIME-Version: 1.0

   Content-Type: multipart/report; report-type=feedback-report;
        boundary="part1_13d.2e68ed54_boundary"

   --part1_13d.2e68ed54_boundary
   Content-Type: text/plain; charset="US-ASCII"
   Content-Transfer-Encoding: 7bit

   This is an email abuse report for an email message received
   from IP 192.0.2.1 on Thu, 8 Mar 2005 14:00:00 EDT.
   For more information about this format please see
   http://tools.ietf.org/html/rfc5965
   Comment: I sell pharmaceuticals, so this is not spam for me.

   --part1_13d.2e68ed54_boundary
   Content-Type: message/feedback-report

   Feedback-Type: not-spam
   User-Agent: SomeGenerator/1.0
   Version: 1

   --part1_13d.2e68ed54_boundary
   Content-Type: message/rfc822
   Content-Disposition: inline
   Received: from mailserver.example.net
        (mailserver.example.net [192.0.2.1])
        by example.com with ESMTP id M63d4137594e46;
        Thu, 08 Mar 2005 14:00:00 -0400
   From: <someone@example.net>
   To: <Undisclosed Recipients>
   Subject: Discount on pharmaceuticals
   MIME-Version: 1.0
   Content-type: text/plain
   Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net
   Date: Thu, 02 Sep 2004 12:31:03 -0500

   Hi, Joe.  I got a lead on a source for discounts on
   pharmaceuticals, and I thought you might be interested.
   [...etc...]
   --part1_13d.2e68ed54_boundary--

                     Example 1: not-spam Report

4. Security Considerations 🚨

Heads up, this part is serious 🚨. All of the security considerations from the Email Feedback Reports specification [RFC5965] carry over to this one 🔒. On top of that, the Email Feedback Reports Applicability Statement [MARF-AS] has important info about trust relationships and other security and integrity stuff for accepting abuse feedback 🛡️.

Here's the big scary part 😱: not-spam reports will likely get used in an attack on a filtering system, by reporting true spam as "not-spam" 💀. Even without any malice, some not-spam reports might be sent in error, or might only apply to the user who sent them 🙈. Operators need to be careful about trusting these reports beyond how they apply to that specific user 🧐.

5. IANA Considerations 📋

IANA has registered the new feedback type name "not-spam", following the instructions in Section 7.3 of the base specification [RFC5965] 🎀.

This was added to the "Feedback Report Type Values" registry:

   Feedback Type Name:  not-spam

   Description:  Indicates that the entity providing the report does not
      consider the message to be spam.  This may be used to correct a
      message that was incorrectly tagged or categorized as spam.

   Published in:  this document

   Status:  current

6. Acknowledgements 🫶

The authors thank Murray S. Kucherawy and Bert Greevenbosch for their discussion and review, and J.D. Falk for suggesting some of the explanatory text 💖.

7. References 📚

7.1. Normative References

   [RFC5965]  Shafranovich, Y., Levine, J., and M. Kucherawy, "An
              Extensible Format for Email Feedback Reports", RFC 5965,
              August 2010.

7.2. Informative References

   [MARF-AS]  Falk, J., "Creation and Use of Email Feedback Reports: An
              Applicability Statement for the Abuse Reporting Format
              (ARF)", Work in Progress, September 2011.

   [OMA-SpamRep-RD]
              Open Mobile Alliance, "Mobile Spam Reporting
              Requirements", Candidate Version 1.0 OMA-RD-SpamRep-V1_0-
              20101123-C, November 2010, <http://
              www.openmobilealliance.org/Technical/release_program/docs/
              SpamRep/V1_0-20101123-C/
              OMA-RD-SpamRep-V1_0-20101123-C.pdf>.

   [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
              "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376,
              September 2011.

Authors' Addresses 🧚

   Kepeng Li
   Huawei Technologies
   Huawei Base, Bantian, Longgang District
   Shenzhen, Guangdong  518129
   P.R. China

   Phone: +86-755-28974289
   EMail: likepeng@huawei.com


   Barry Leiba
   Huawei Technologies

   Phone: +1 646 827 0648
   EMail: barryleiba@computer.org
   URI:   http://internetmessagingtechnology.org/
📦 where this page comes from