idnits 2.17.1 draft-ietf-marf-not-spam-feedback-00.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 (July 2, 2011) is 4682 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 (-15) exists of draft-ietf-dkim-rfc4871bis-13 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: January 3, 2012 July 2, 2011 7 Email Feedback Report Type Value : not-spam 8 draft-ietf-marf-not-spam-feedback-00 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 January 3, 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 . . . . . . . . . . . . . . . . . . . 5 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 7.1. Normative References . . . . . . . . . . . . . . . . . . . . 6 66 7.2. Informative References . . . . . . . . . . . . . . . . . . . 6 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 mail client receives an email message that was 87 tagged as spam, either by the mail system or accidentally by the 88 user, but the end user finds that actually it is not spam. The mail 89 client accepts the end user's report instruction and retrieves 90 information related to the message, and reports this email as not- 91 spam to the mail operator. When the mail operator receives the 92 report, it can determine what action is appropriate for the 93 particular message and user. (The requirement for a not-spam report 94 type is from the Open Mobile Alliance (OMA) Spam Report Requirement 95 Document [OMA-SpamRep-RD].) 97 For example, in response to a "not-spam" report the mail system can 98 remove the spam tag or change the category, possibly preventing 99 future similar mail for this user from being marked as spam. The 100 report can be used to adjust the training of an automated classifier. 101 After processing the report, the mail operator can send a 102 notification to the mail client about the processing result. 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 1.2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. These 126 terms take their normative values only when presented in UPPER CASE. 128 2. Feedback Report Type: Not-Spam 130 This document only defines a new feedback report type, "not-spam", 131 extending the Email Feedback Reports specification [RFC5965]. 133 In the first MIME part of the feedback report message, the end user 134 or the mail client MAY add information to indicate why the message is 135 not spam -- for example, because the originator or its domain is well 136 known. 138 3. Example 140 In the example, Joe, a pharmaceuticals sales representative, has 141 received a message about discount pharmaceuticals. Because that is a 142 frequent subject of spam email, the message has been marked as spam 143 -- incorrectly, in this case. Joe has reported it as "not-spam", and 144 this is an example of the report. 146 Note that the message is DKIM-signed [I-D.ietf-dkim-rfc4871bis], a 147 good security practice as suggested in RFC 5965 section 8.2 148 [RFC5965]. 150 DKIM-Signature: v=1; a=rsa-sha256; s=abuse; d=example.com; 151 c=simple/simple; q=dns/txt; i=abusedesk@example.com; 152 h=From:Date:Subject:To:Message-ID:MIME-Version:Content-Type; 153 bh=iF4dMNYs/KepE0HuwfukJCDyjkduUzZFiaHqO9DMIPU=; 154 b=e+BF8DCHFGqCp7/pExleNz7pVaLEoT+uWj/8H9DoZpxFI1vNnCTDu14w5v 155 ze4mqJkldudVI0JspsYHTYeomhPklCV4F95GfwpM5W+ziUOv7AySTfygPW 156 EerczqZwAK88//oaYCFXq3XV9T/z+zlLp3rrirKGmCMCPPcbdSGv/Eg= 157 From: 158 Date: Thu, 8 Mar 2005 17:40:36 EDT 159 Subject: FW: Discount on pharmaceuticals 160 To: 161 Message-ID: <20030712040037.46341.5F8J@example.com> 162 MIME-Version: 1.0 163 Content-Type: multipart/report; report-type=feedback-report; 164 boundary="part1_13d.2e68ed54_boundary" 166 --part1_13d.2e68ed54_boundary 167 Content-Type: text/plain; charset="US-ASCII" 168 Content-Transfer-Encoding: 7bit 170 This is an email abuse report for an email message received 171 from IP 192.0.2.1 on Thu, 8 Mar 2005 14:00:00 EDT. 172 For more information about this format please see 173 http://www.mipassoc.org/arf/. 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. 210 Not-spam reports could possibly be used in an attack on a filtering 211 system, reporting true spam as "not-spam". Even in absence of 212 malice, some not-spam reports might be made in error, or will only 213 apply to the user sending the report. Operators need to be careful 214 in trusting such reports, beyond their applicability to the specific 215 user in question. 217 5. IANA Considerations 219 Registration is requested for the newly defined feedback type name: 220 "not-spam", according to the instructions in section 7.3 of the base 221 specification [RFC5965]. 223 Please add the following to the "Feedback Report Type Values" 224 registry: 225 Feedback Type Name: not-spam 226 Description: Indicates that a message is not spam. This may be used 227 to correct a message that was incorrectly tagged or categorized 228 as spam. 229 Published in: this document 230 Status: current 232 6. Acknowledgements 234 The authors would like thank Murray S. Kucherawy and Bert 235 Greevenbosch for their discussion and review, and J.D. Falk for 236 suggesting some explanatory text. 238 7. References 240 7.1. Normative References 242 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 243 Requirement Levels", BCP 14, RFC 2119, March 1997. 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-dkim-rfc4871bis] 252 Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 253 Identified Mail (DKIM) Signatures", 254 draft-ietf-dkim-rfc4871bis-13 (work in progress), 255 June 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 Authors' Addresses 264 Kepeng Li 265 Huawei Technologies 266 Huawei Base, Bantian, Longgang District 267 Shenzhen, Guangdong 518129 268 P. R. China 270 Phone: +86-755-28974289 271 Email: likepeng@huawei.com 273 Barry Leiba 274 Huawei Technologies 276 Phone: +1 646 827 0648 277 Email: barryleiba@computer.org 278 URI: http://internetmessagingtechnology.org/