From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6430.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc6430.txt (limited to 'doc/rfc/rfc6430.txt') diff --git a/doc/rfc/rfc6430.txt b/doc/rfc/rfc6430.txt new file mode 100644 index 0000000..6ab1a5d --- /dev/null +++ b/doc/rfc/rfc6430.txt @@ -0,0 +1,395 @@ + + + + + + +Internet Engineering Task Force (IETF) K. Li +Request for Comments: 6430 B. Leiba +Category: Standards Track Huawei Technologies +ISSN: 2070-1721 November 2011 + + + Email Feedback Report Type Value: not-spam + +Abstract + + This document defines a new Abuse Reporting Format (ARF) feedback + report type value: "not-spam". It can be used to report an email + message that was mistakenly marked as spam. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6430. + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + + + +Li & Leiba Standards Track [Page 1] + +RFC 6430 Email Feedback Type: not-spam November 2011 + + +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 + + In RFC 5965 [RFC5965], an Abuse Reporting Format (ARF) is defined for + reporting email abuse. Currently, two feedback report types are + defined that are related to the spam problem and that can be used to + report abusive or fraudulent email messages: + + o abuse: indicates unsolicited email or some other kind of email + abuse. + + o fraud: indicates some kind of fraud or phishing activity. + + This specification defines a new feedback report type: "not-spam". + It can be used to report a message that was mistakenly marked as + spam. + +1.1. Discussion + + In some cases, the email client receives an email message that was + incorrectly tagged as spam, perhaps by the email system, or + accidentally by the user. The email client accepts the end user's + "not-spam" report instruction, retrieves information related to the + message, and reports this email as not-spam to the email operator. + When the email operator receives the report, it can determine what + action is appropriate for the particular message and user. (The + requirement for a not-spam report type is from the Open Mobile + Alliance (OMA) Spam Report Requirement Document [OMA-SpamRep-RD].) + + For example, in response to a "not-spam" report, the email system can + remove the spam tag or otherwise reclassify the message, possibly + preventing similar email for this user from being marked as spam in + the future. The report can be used to adjust the training of an + automated classifier. After processing the report, the email + + + + + +Li & Leiba Standards Track [Page 2] + +RFC 6430 Email Feedback Type: not-spam November 2011 + + + operator might send a notification to the email client about the + processing result (for example, by moving the message from one + mailbox to another, such as from "Junk" to "Inbox"). + + In most cases, "not-spam" reports will probably not be taken on their + own, but will be considered along with other information, analysis of + the message, etc. Because different users have different needs and + different views of what constitutes spam, reports from one user might + or might not be applicable to others. And because users might + sometimes press a "report not spam" button accidentally, immediate + strong action, such as marking all similar messages as "good" based + on a single report, is probably not the right approach. Recipients + of "not-spam" reports need to consider what's right in their + environments. + + There are anti-spam systems that use (non-standard) "not spam" + feedback today. All of them take the reports and mix them with other + spam reports and other data, using their own algorithms, to determine + appropriate action. In no case do the existing systems use a "not + spam" report as an immediate, automatic override. + + The feedback types "abuse" and "not-spam" can be taken as opposites. + A mistaken "not-spam" report could be countermanded by a subsequent + "abuse" report from the same user, and an operator could consider + collected reports of "abuse" and "not-spam" in making future + assessments. + +2. Feedback Report Type: not-spam + + This document defines a 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 information to indicate why the message + is not considered as spam -- for example, because the originator or + its domain is well known. + +3. Example + + In the example, Joe, a pharmaceuticals sales representative, has + received a message about discount pharmaceuticals. Because that is a + frequent subject of spam email, the message has been marked as spam + -- incorrectly, in this case. Joe has reported it as "not-spam", and + this is an example of the report, shortened (the "[...etc...]" part) + for presentation here. + + + + + + +Li & Leiba Standards Track [Page 3] + +RFC 6430 Email Feedback Type: not-spam November 2011 + + + Note that the message has been signed using DomainKeys Identified + Mail (DKIM) [RFC6376] -- a good security practice as suggested in + Section 8.2 of RFC 5965 [RFC5965]. + + 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: + Date: Thu, 8 Mar 2005 17:40:36 EDT + Subject: FW: Discount on pharmaceuticals + To: + 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 + + + + + + + + + + +Li & Leiba Standards Track [Page 4] + +RFC 6430 Email Feedback Type: not-spam November 2011 + + + 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: + To: + 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 + + All of the security considerations from the Email Feedback Reports + specification [RFC5965] are inherited here. In addition, the Email + Feedback Reports Applicability Statement [MARF-AS] contains important + information about trust relationships and other security- and + integrity-related aspects of accepting abuse feedback. + + In particular, not-spam reports will likely be used in an attack on a + filtering system, reporting true spam as "not-spam". Even in absence + of malice, some not-spam reports might be made in error, or will only + apply to the user sending the report. Operators need to be careful + in trusting such reports, beyond their applicability to the specific + user in question. + + + + + + + + + + + + + + + + + + +Li & Leiba Standards Track [Page 5] + +RFC 6430 Email Feedback Type: not-spam November 2011 + + +5. IANA Considerations + + IANA has registered the newly defined feedback type name: "not-spam", + according to the instructions in Section 7.3 of the base + specification [RFC5965]. + + The following has been 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 would like to thank Murray S. Kucherawy and Bert + Greevenbosch for their discussion and review, and J.D. Falk for + suggesting some 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, . + + + + + +Li & Leiba Standards Track [Page 6] + +RFC 6430 Email Feedback Type: not-spam November 2011 + + + [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/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Li & Leiba Standards Track [Page 7] + -- cgit v1.2.3