idnits 2.17.1 draft-ietf-marf-not-spam-feedback-02.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 19, 2011) is 4574 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 22, 2012 September 19, 2011 7 Email Feedback Report Type Value : not-spam 8 draft-ietf-marf-not-spam-feedback-02 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 a message 14 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 22, 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 . . . . . . . . . . . . . . . . . . . 5 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 7.1. Normative References . . . . . . . . . . . . . . . . . . . . 6 65 7.2. Informative References . . . . . . . . . . . . . . . . . . . 6 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 "not spam" feedback today. All 116 of them take the reports and mix them with other spam reports and 117 other data, using their own algorithms, to determine appropriate 118 action. In no case do the existing systems use a "not spam" report 119 as an immediate, automatic override. 121 2. Feedback Report Type: Not-Spam 123 This document only defines a new feedback report type, "not-spam", 124 extending the Email Feedback Reports specification [RFC5965]. 126 In the first MIME part of the feedback report message, the end user 127 or the email client can add information to indicate why the message 128 is not spam -- for example, because the originator or its domain is 129 well known. 131 3. Example 133 In the example, Joe, a pharmaceuticals sales representative, has 134 received a message about discount pharmaceuticals. Because that is a 135 frequent subject of spam email, the message has been marked as spam 136 -- incorrectly, in this case. Joe has reported it as "not-spam", and 137 this is an example of the report, shortened (the "[...etc...]" part) 138 for presentation here. 140 Note that the message is DKIM-signed [I-D.ietf-dkim-rfc4871bis], a 141 good security practice as suggested in RFC 5965 section 8.2 142 [RFC5965]. [[anchor3: RFC Editor: please replace the DKIM citation 143 with a reference to RFC 6376, once it's published.]] 145 DKIM-Signature: v=1; a=rsa-sha256; s=abuse; d=example.com; 146 c=simple/simple; q=dns/txt; i=abusedesk@example.com; 147 h=From:Date:Subject:To:Message-ID:MIME-Version:Content-Type; 148 bh=iF4dMNYs/KepE0HuwfukJCDyjkduUzZFiaHqO9DMIPU=; 149 b=e+BF8DCHFGqCp7/pExleNz7pVaLEoT+uWj/8H9DoZpxFI1vNnCTDu14w5v 150 ze4mqJkldudVI0JspsYHTYeomhPklCV4F95GfwpM5W+ziUOv7AySTfygPW 151 EerczqZwAK88//oaYCFXq3XV9T/z+zlLp3rrirKGmCMCPPcbdSGv/Eg= 152 From: 153 Date: Thu, 8 Mar 2005 17:40:36 EDT 154 Subject: FW: Discount on pharmaceuticals 155 To: 156 Message-ID: <20030712040037.46341.5F8J@example.com> 157 MIME-Version: 1.0 158 Content-Type: multipart/report; report-type=feedback-report; 159 boundary="part1_13d.2e68ed54_boundary" 161 --part1_13d.2e68ed54_boundary 162 Content-Type: text/plain; charset="US-ASCII" 163 Content-Transfer-Encoding: 7bit 165 This is an email abuse report for an email message received 166 from IP 192.0.2.1 on Thu, 8 Mar 2005 14:00:00 EDT. 167 For more information about this format please see 168 http://tools.ietf.org/html/rfc5965 169 Comment: I sell pharmaceuticals, so this is not spam for me. 171 --part1_13d.2e68ed54_boundary 172 Content-Type: message/feedback-report 174 Feedback-Type: not-spam 175 User-Agent: SomeGenerator/1.0 176 Version: 1 178 --part1_13d.2e68ed54_boundary 179 Content-Type: message/rfc822 180 Content-Disposition: inline 182 Received: from mailserver.example.net 183 (mailserver.example.net [192.0.2.1]) 184 by example.com with ESMTP id M63d4137594e46; 185 Thu, 08 Mar 2005 14:00:00 -0400 186 From: 187 To: 188 Subject: Discount on pharmaceuticals 189 MIME-Version: 1.0 190 Content-type: text/plain 191 Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net 192 Date: Thu, 02 Sep 2004 12:31:03 -0500 194 Hi, Joe. I got a lead on a source for discounts on 195 pharmaceuticals, and I thought you might be interested. 196 [...etc...] 197 --part1_13d.2e68ed54_boundary-- 199 Example 1: Not-spam report 201 4. Security Considerations 203 All of the Security Considerations from the Email Feedback Reports 204 specification [RFC5965] are inherited here. In addition, the Email 205 Feedback Reports Applicability Statement [I-D.ietf-marf-as] contains 206 important information about trust relationships and other security- 207 and integrity-related aspects of accepting abuse feedback. 209 In particular, not-spam reports will likely be used in an attack on a 210 filtering system, reporting true spam as "not-spam". Even in absence 211 of malice, some not-spam reports might be made in error, or will only 212 apply to the user sending the report. Operators need to be careful 213 in trusting such reports, beyond their applicability to the specific 214 user in question. 216 5. IANA Considerations 218 Registration is requested for the newly defined feedback type name: 219 "not-spam", according to the instructions in section 7.3 of the base 220 specification [RFC5965]. 222 Please add the following to the "Feedback Report Type Values" 223 registry: 224 Feedback Type Name: not-spam 225 Description: Indicates that a message is not spam. This may be used 226 to correct a message that was incorrectly tagged or categorized 227 as spam. 228 Published in: this document 229 Status: current 231 6. Acknowledgements 233 The authors would like thank Murray S. Kucherawy and Bert 234 Greevenbosch for their discussion and review, and J.D. Falk for 235 suggesting some explanatory text. 237 7. References 239 7.1. Normative References 241 [RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An 242 Extensible Format for Email Feedback Reports", RFC 5965, 243 August 2010. 245 7.2. Informative References 247 [I-D.ietf-dkim-rfc4871bis] 248 Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 249 Identified Mail (DKIM) Signatures", 250 draft-ietf-dkim-rfc4871bis-15 (work in progress), 251 July 2011. 253 [I-D.ietf-marf-as] 254 Falk, J., "Creation and Use of Email Feedback Reports: An 255 Applicability Statement for the Abuse Reporting Format 256 (ARF)", draft-ietf-marf-as-00 (work in progress), 257 September 2011. 259 [OMA-SpamRep-RD] 260 Open Mobile Alliance, "Mobile Spam Reporting 261 Requirements", OMA-RD-SpamRep-V1_0 20101123-C, 262 November 2010. 264 Authors' Addresses 266 Kepeng Li 267 Huawei Technologies 268 Huawei Base, Bantian, Longgang District 269 Shenzhen, Guangdong 518129 270 P. R. China 272 Phone: +86-755-28974289 273 Email: likepeng@huawei.com 275 Barry Leiba 276 Huawei Technologies 278 Phone: +1 646 827 0648 279 Email: barryleiba@computer.org 280 URI: http://internetmessagingtechnology.org/