summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6430.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6430.txt')
-rw-r--r--doc/rfc/rfc6430.txt395
1 files changed, 395 insertions, 0 deletions
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: <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
+
+
+
+
+
+
+
+
+
+
+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: <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
+
+ 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, <http://
+ www.openmobilealliance.org/Technical/release_program/docs/
+ SpamRep/V1_0-20101123-C/
+ OMA-RD-SpamRep-V1_0-20101123-C.pdf>.
+
+
+
+
+
+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]
+