idnits 2.17.1 draft-ietf-marf-not-spam-feedback-01.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 (August 12, 2011) is 4634 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: February 13, 2012 August 12, 2011 7 Email Feedback Report Type Value : not-spam 8 draft-ietf-marf-not-spam-feedback-01 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 February 13, 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 52 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Feedback Report Type: Not-Spam . . . . . . . . . . . . . . . 4 56 3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 7.1. Normative References . . . . . . . . . . . . . . . . . . . . 6 66 7.2. Informative References . . . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 In RFC 5965 [RFC5965], an Abuse Reporting Format (ARF) is defined for 73 reporting email abuse. Currently two feedback report types are 74 defined that are related to the spam problem, and that can be used to 75 report abusive or fraudulent email messages: 76 o abuse: indicates unsolicited email or some other kind of email 77 abuse. 78 o fraud: indicates some kind of fraud or phishing activity. 80 This specification defines a new feedback report type: "not-spam". 81 It can be used to report a message that was mistakenly marked as 82 spam. 84 1.1. Discussion 86 In some cases, the email client receives an email message that was 87 incorrectly tagged as spam, perhaps by the email system, or 88 accidentally by the user. The email client accepts the end user's 89 "not-spam" report instruction, retrieves information related to the 90 message, and reports this email as not-spam to the email operator. 91 When the email operator receives the report, it can determine what 92 action is appropriate for the particular message and user. (The 93 requirement for a not-spam report type is from the Open Mobile 94 Alliance (OMA) Spam Report Requirement Document [OMA-SpamRep-RD].) 96 For example, in response to a "not-spam" report the email system can 97 remove the spam tag or otherwise reclassify the message, possibly 98 preventing future similar email for this user from being marked as 99 spam. The report can be used to adjust the training of an automated 100 classifier. After processing the report, the email operator might 101 send a notification to the email client about the processing result 102 (for example, by moving the message from one mailbox to another, such 103 as from "Junk" to "Inbox"). 105 In most cases, "not-spam" reports will probably not be taken on their 106 own, but will be considered along with other information, analysis of 107 the message, etc. Because different users have different needs and 108 different views of what constitutes spam, reports from one user might 109 or might not be applicable to others. And because users might 110 sometimes press a "report not spam" button accidentally, immediate 111 strong action, such as marking all similar messages as "good" based 112 on a single report, is probably not the right approach. Recipients 113 of "not-spam" reports need to consider what's right in their 114 environments. 116 There are anti-spam systems that use "not spam" feedback today. All 117 of them take the reports and mix them with other spam reports and 118 other data, using their own algorithms, to determine appropriate 119 action. In no case do the existing systems use a "not spam" report 120 as an immediate, automatic override. 122 1.2. Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. These 127 terms take their normative values only when presented in UPPER CASE. 129 2. Feedback Report Type: Not-Spam 131 This document only defines a new feedback report type, "not-spam", 132 extending the Email Feedback Reports specification [RFC5965]. 134 In the first MIME part of the feedback report message, the end user 135 or the email client MAY add information to indicate why the message 136 is not spam -- for example, because the originator or its domain is 137 well known. 139 3. Example 141 In the example, Joe, a pharmaceuticals sales representative, has 142 received a message about discount pharmaceuticals. Because that is a 143 frequent subject of spam email, the message has been marked as spam 144 -- incorrectly, in this case. Joe has reported it as "not-spam", and 145 this is an example of the report. 147 Note that the message is DKIM-signed [I-D.ietf-dkim-rfc4871bis], a 148 good security practice as suggested in RFC 5965 section 8.2 149 [RFC5965]. 151 DKIM-Signature: v=1; a=rsa-sha256; s=abuse; d=example.com; 152 c=simple/simple; q=dns/txt; i=abusedesk@example.com; 153 h=From:Date:Subject:To:Message-ID:MIME-Version:Content-Type; 154 bh=iF4dMNYs/KepE0HuwfukJCDyjkduUzZFiaHqO9DMIPU=; 155 b=e+BF8DCHFGqCp7/pExleNz7pVaLEoT+uWj/8H9DoZpxFI1vNnCTDu14w5v 156 ze4mqJkldudVI0JspsYHTYeomhPklCV4F95GfwpM5W+ziUOv7AySTfygPW 157 EerczqZwAK88//oaYCFXq3XV9T/z+zlLp3rrirKGmCMCPPcbdSGv/Eg= 158 From: 159 Date: Thu, 8 Mar 2005 17:40:36 EDT 160 Subject: FW: Discount on pharmaceuticals 161 To: 162 Message-ID: <20030712040037.46341.5F8J@example.com> 163 MIME-Version: 1.0 164 Content-Type: multipart/report; report-type=feedback-report; 165 boundary="part1_13d.2e68ed54_boundary" 167 --part1_13d.2e68ed54_boundary 168 Content-Type: text/plain; charset="US-ASCII" 169 Content-Transfer-Encoding: 7bit 171 This is an email abuse report for an email message received 172 from IP 192.0.2.1 on Thu, 8 Mar 2005 14:00:00 EDT. 173 For more information about this format please see 174 http://www.mipassoc.org/arf/. 175 Comment: I sell pharmaceuticals, so this is not spam for me. 177 --part1_13d.2e68ed54_boundary 178 Content-Type: message/feedback-report 180 Feedback-Type: not-spam 181 User-Agent: SomeGenerator/1.0 182 Version: 1 184 --part1_13d.2e68ed54_boundary 185 Content-Type: message/rfc822 186 Content-Disposition: inline 188 Received: from mailserver.example.net 189 (mailserver.example.net [192.0.2.1]) 190 by example.com with ESMTP id M63d4137594e46; 191 Thu, 08 Mar 2005 14:00:00 -0400 192 From: 193 To: 194 Subject: Discount on pharmaceuticals 195 MIME-Version: 1.0 196 Content-type: text/plain 197 Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net 198 Date: Thu, 02 Sep 2004 12:31:03 -0500 200 Hi, Joe. I got a lead on a source for discounts on 201 pharmaceuticals, and I thought you might be interested. 202 [...etc...] 203 --part1_13d.2e68ed54_boundary-- 205 Example 1: Not-spam report 207 4. Security Considerations 209 All of the Security Considerations from the Email Feedback Reports 210 specification [RFC5965] are inherited here. 212 Not-spam reports could possibly be used in an attack on a filtering 213 system, reporting true spam as "not-spam". Even in absence of 214 malice, some not-spam reports might be made in error, or will only 215 apply to the user sending the report. Operators need to be careful 216 in trusting such reports, beyond their applicability to the specific 217 user in question. 219 5. IANA Considerations 221 Registration is requested for the newly defined feedback type name: 222 "not-spam", according to the instructions in section 7.3 of the base 223 specification [RFC5965]. 225 Please add the following to the "Feedback Report Type Values" 226 registry: 227 Feedback Type Name: not-spam 228 Description: Indicates that a message is not spam. This may be used 229 to correct a message that was incorrectly tagged or categorized 230 as spam. 231 Published in: this document 232 Status: current 234 6. Acknowledgements 236 The authors would like thank Murray S. Kucherawy and Bert 237 Greevenbosch for their discussion and review, and J.D. Falk for 238 suggesting some explanatory text. 240 7. References 242 7.1. Normative References 244 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 245 Requirement Levels", BCP 14, RFC 2119, March 1997. 247 [RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An 248 Extensible Format for Email Feedback Reports", RFC 5965, 249 August 2010. 251 7.2. Informative References 253 [I-D.ietf-dkim-rfc4871bis] 254 Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 255 Identified Mail (DKIM) Signatures", 256 draft-ietf-dkim-rfc4871bis-15 (work in progress), 257 July 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/