idnits 2.17.1 draft-ietf-marf-not-spam-feedback-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 22, 2011) is 4598 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-16) exists of draft-ietf-marf-as-00 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 marf K. Li 3 Internet-Draft B. Leiba 4 Intended status: Standards Track Huawei Technologies 5 Expires: March 25, 2012 September 22, 2011 7 Email Feedback Report Type Value : not-spam 8 draft-ietf-marf-not-spam-feedback-03 10 Abstract 12 This document defines a new Abuse Reporting Format (ARF) feedback 13 report type value: "not-spam". It can be used to report an email 14 message that was mistakenly marked as spam. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on March 25, 2012. 33 Copyright Notice 35 Copyright (c) 2011 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Feedback Report Type: Not-Spam . . . . . . . . . . . . . . . 4 55 3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 7.1. Normative References . . . . . . . . . . . . . . . . . . . . 6 65 7.2. Informative References . . . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 In RFC 5965 [RFC5965], an Abuse Reporting Format (ARF) is defined for 72 reporting email abuse. Currently two feedback report types are 73 defined that are related to the spam problem, and that can be used to 74 report abusive or fraudulent email messages: 75 o abuse: indicates unsolicited email or some other kind of email 76 abuse. 77 o fraud: indicates some kind of fraud or phishing activity. 79 This specification defines a new feedback report type: "not-spam". 80 It can be used to report a message that was mistakenly marked as 81 spam. 83 1.1. Discussion 85 In some cases, the email client receives an email message that was 86 incorrectly tagged as spam, perhaps by the email system, or 87 accidentally by the user. The email client accepts the end user's 88 "not-spam" report instruction, retrieves information related to the 89 message, and reports this email as not-spam to the email operator. 90 When the email operator receives the report, it can determine what 91 action is appropriate for the particular message and user. (The 92 requirement for a not-spam report type is from the Open Mobile 93 Alliance (OMA) Spam Report Requirement Document [OMA-SpamRep-RD].) 95 For example, in response to a "not-spam" report the email system can 96 remove the spam tag or otherwise reclassify the message, possibly 97 preventing future similar email for this user from being marked as 98 spam. The report can be used to adjust the training of an automated 99 classifier. After processing the report, the email operator might 100 send a notification to the email client about the processing result 101 (for example, by moving the message from one mailbox to another, such 102 as from "Junk" to "Inbox"). 104 In most cases, "not-spam" reports will probably not be taken on their 105 own, but will be considered along with other information, analysis of 106 the message, etc. Because different users have different needs and 107 different views of what constitutes spam, reports from one user might 108 or might not be applicable to others. And because users might 109 sometimes press a "report not spam" button accidentally, immediate 110 strong action, such as marking all similar messages as "good" based 111 on a single report, is probably not the right approach. Recipients 112 of "not-spam" reports need to consider what's right in their 113 environments. 115 There are anti-spam systems that use (non-standard) "not spam" 116 feedback today. All of them take the reports and mix them with other 117 spam reports and other data, using their own algorithms, to determine 118 appropriate action. In no case do the existing systems use a "not 119 spam" report as an immediate, automatic override. 121 The feedback types "abuse" and "not-spam" can be taken as opposites. 122 A mistaken "not-spam" report could be countermanded by a subsequent 123 "abuse" report from the same user, and an operator could consider 124 collected reports of "abuse" and "not-spam" in making future 125 assessments. 127 2. Feedback Report Type: Not-Spam 129 This document only defines a new feedback report type, "not-spam", 130 extending the Email Feedback Reports specification [RFC5965]. 132 In the first MIME part of the feedback report message, the end user 133 or the email client can add information to indicate why the message 134 is not considered as spam -- for example, because the originator or 135 its domain is well known. 137 3. Example 139 In the example, Joe, a pharmaceuticals sales representative, has 140 received a message about discount pharmaceuticals. Because that is a 141 frequent subject of spam email, the message has been marked as spam 142 -- incorrectly, in this case. Joe has reported it as "not-spam", and 143 this is an example of the report, shortened (the "[...etc...]" part) 144 for presentation here. 146 Note that the message is DKIM-signed [RFC6376], a good security 147 practice as suggested in RFC 5965 section 8.2 [RFC5965]. 149 DKIM-Signature: v=1; a=rsa-sha256; s=abuse; d=example.com; 150 c=simple/simple; q=dns/txt; i=abusedesk@example.com; 151 h=From:Date:Subject:To:Message-ID:MIME-Version:Content-Type; 152 bh=iF4dMNYs/KepE0HuwfukJCDyjkduUzZFiaHqO9DMIPU=; 153 b=e+BF8DCHFGqCp7/pExleNz7pVaLEoT+uWj/8H9DoZpxFI1vNnCTDu14w5v 154 ze4mqJkldudVI0JspsYHTYeomhPklCV4F95GfwpM5W+ziUOv7AySTfygPW 155 EerczqZwAK88//oaYCFXq3XV9T/z+zlLp3rrirKGmCMCPPcbdSGv/Eg= 156 From: 157 Date: Thu, 8 Mar 2005 17:40:36 EDT 158 Subject: FW: Discount on pharmaceuticals 159 To: 160 Message-ID: <20030712040037.46341.5F8J@example.com> 161 MIME-Version: 1.0 162 Content-Type: multipart/report; report-type=feedback-report; 163 boundary="part1_13d.2e68ed54_boundary" 165 --part1_13d.2e68ed54_boundary 166 Content-Type: text/plain; charset="US-ASCII" 167 Content-Transfer-Encoding: 7bit 169 This is an email abuse report for an email message received 170 from IP 192.0.2.1 on Thu, 8 Mar 2005 14:00:00 EDT. 171 For more information about this format please see 172 http://tools.ietf.org/html/rfc5965 173 Comment: I sell pharmaceuticals, so this is not spam for me. 175 --part1_13d.2e68ed54_boundary 176 Content-Type: message/feedback-report 178 Feedback-Type: not-spam 179 User-Agent: SomeGenerator/1.0 180 Version: 1 182 --part1_13d.2e68ed54_boundary 183 Content-Type: message/rfc822 184 Content-Disposition: inline 186 Received: from mailserver.example.net 187 (mailserver.example.net [192.0.2.1]) 188 by example.com with ESMTP id M63d4137594e46; 189 Thu, 08 Mar 2005 14:00:00 -0400 190 From: 191 To: 192 Subject: Discount on pharmaceuticals 193 MIME-Version: 1.0 194 Content-type: text/plain 195 Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net 196 Date: Thu, 02 Sep 2004 12:31:03 -0500 198 Hi, Joe. I got a lead on a source for discounts on 199 pharmaceuticals, and I thought you might be interested. 200 [...etc...] 201 --part1_13d.2e68ed54_boundary-- 203 Example 1: Not-spam report 205 4. Security Considerations 207 All of the Security Considerations from the Email Feedback Reports 208 specification [RFC5965] are inherited here. In addition, the Email 209 Feedback Reports Applicability Statement [I-D.ietf-marf-as] contains 210 important information about trust relationships and other security- 211 and integrity-related aspects of accepting abuse feedback. 213 In particular, not-spam reports will likely be used in an attack on a 214 filtering system, reporting true spam as "not-spam". Even in absence 215 of malice, some not-spam reports might be made in error, or will only 216 apply to the user sending the report. Operators need to be careful 217 in trusting such reports, beyond their applicability to the specific 218 user in question. 220 5. IANA Considerations 222 Registration is requested for the newly defined feedback type name: 223 "not-spam", according to the instructions in section 7.3 of the base 224 specification [RFC5965]. 226 Please add the following to the "Feedback Report Type Values" 227 registry: 228 Feedback Type Name: not-spam 229 Description: Indicates that the entity providing the report does not 230 consider the message to be spam. This may be used to correct a 231 message that was incorrectly tagged or categorized as spam. 232 Published in: this document 233 Status: current 235 6. Acknowledgements 237 The authors would like thank Murray S. Kucherawy and Bert 238 Greevenbosch for their discussion and review, and J.D. Falk for 239 suggesting some explanatory text. 241 7. References 243 7.1. Normative References 245 [RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An 246 Extensible Format for Email Feedback Reports", RFC 5965, 247 August 2010. 249 7.2. Informative References 251 [I-D.ietf-marf-as] 252 Falk, J., "Creation and Use of Email Feedback Reports: An 253 Applicability Statement for the Abuse Reporting Format 254 (ARF)", draft-ietf-marf-as-00 (work in progress), 255 September 2011. 257 [OMA-SpamRep-RD] 258 Open Mobile Alliance, "Mobile Spam Reporting 259 Requirements", OMA-RD-SpamRep-V1_0 20101123-C, 260 November 2010. 262 [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 263 Identified Mail (DKIM) Signatures", RFC 6376, 264 September 2011. 266 Authors' Addresses 268 Kepeng Li 269 Huawei Technologies 270 Huawei Base, Bantian, Longgang District 271 Shenzhen, Guangdong 518129 272 P. R. China 274 Phone: +86-755-28974289 275 Email: likepeng@huawei.com 277 Barry Leiba 278 Huawei Technologies 280 Phone: +1 646 827 0648 281 Email: barryleiba@computer.org 282 URI: http://internetmessagingtechnology.org/