idnits 2.17.1 draft-ietf-marf-as-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 draft header indicates that this document updates RFC5965, but the abstract doesn't seem to directly say this. It does mention RFC5965 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 28, 2011) is 4474 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) ** Downref: Normative reference to an Informational RFC: RFC 5598 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 4408 (Obsoleted by RFC 7208) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MARF Working Group J. Falk 3 Internet-Draft Return Path 4 Updates: 5965 (if approved) M. Kucherawy, Ed. 5 Intended status: Standards Track Cloudmark 6 Expires: June 30, 2012 December 28, 2011 8 Creation and Use of Email Feedback Reports: An Applicability Statement 9 for the Abuse Reporting Format (ARF) 10 draft-ietf-marf-as-02 12 Abstract 14 RFC 5965 defines an extensible, machine-readable format intended for 15 mail operators to report feedback about received email to other 16 parties. This document describes common methods for utilizing this 17 format for abuse reporting. Mailbox Providers of any size, mail 18 sending entities, and end users can use these methods as a basis to 19 create procedures that best suit them. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on June 30, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 1. Introduction 55 The Abuse Reporting Format (ARF) was initially developed for two very 56 specific use cases. Initially, it was intended to be used for 57 reporting feedback between large email operators, or from large email 58 operators to end user network access operators, any of whom could be 59 presumed to have automated abuse-handling systems. Secondarily, it 60 is used by those same large mail operators to send those same reports 61 to other entities, including those involved in sending bulk email for 62 commercial purposes. In either case, the reports would be triggered 63 by direct end user action such as clicking on a "report spam" button 64 in their email client. 66 Though other uses for the format defined in [RFC5965] have been 67 discussed (and may be documented similarly in the future), abuse 68 remains the primary application. 70 The purpose for reporting abusive messages is to stop recurrences. 71 The methods described in this document focus on automating abuse 72 reporting as much as practical, so as to minimize the work of a 73 site's abuse team. There are further reasons why abuse feedback 74 generation is worthwhile, such as instruction of mail filters or 75 reputation trackers, or to initiate investigations of particularly 76 egregious abuses. These other applications are not discussed in this 77 memo. 79 Further introduction to this topic may be found in [RFC6449]. 81 2. Definitions 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119], and are 86 intended to replace the Requirement Levels described in Section 3.3 87 of [RFC2026]. 89 Some of the terminology used in this document is taken from 90 [RFC5598]. 92 "Mailbox Provider" refers to an organization that accepts, stores, 93 and offers access to [RFC5322] messages ("email messages") for end 94 users. Such an organization has typically implemented SMTP 95 ([RFC5321]), and might provide access to messages through IMAP 96 ([RFC3501]), POP ([RFC1939]), a proprietary interface designed for 97 HTTP ([RFC2616]), or a proprietary protocol. 99 3. Applicability Statement 101 [RFC Editor: please remove this section prior to publication.] 103 NOTE TO IESG: This document is part of the experiment to reintroduce 104 Applicability Statements, as defined in Section 3.2 of [RFC2026], to 105 the Applications Area. 107 4. Discussion 109 [RFC Editor: please remove this section prior to publication.] 111 This document is being discussed within the IETF MARF Working Group, 112 on the marf@ietf.org mailing list. 114 5. Solicited and Unsolicited Reports 116 The original application of [RFC5965], and still by far the most 117 common, is when two mail systems make a private agreement to exchange 118 abuse reports, usually reports due to recipients manually reporting 119 messages as spam. We refer to these as solicited reports. 121 Other uses for ARF involve reports sent between parties that don't 122 know each other, with the recipient address typically being 123 abuse@domain (see [RFC2142]), looked up via WHOIS, or using other 124 heuristics. The reports may be manual, or automated due to hitting 125 spam traps, scored high by spam filters, or anything else that the 126 sender of the report considers to merit an abuse report. 128 In either case, where an abusive message is signed using a domain- 129 level authentication technology such as DKIM ([RFC6376]) or SPF 130 ([RFC4408]), the domain that has been verified by the authentication 131 mechanism is likely a reasonable candidate for receiving feedback 132 about the message. 134 6. Creating and Sending Complaint-Based Solicited Reports 136 1. A Mailbox Provider receives reports of abusive or unwanted mail 137 from its users, most often by providing a "report spam" button 138 (or similar nomenclature) in the MUA. The method of transferring 139 this message and any associated metadata from the MUA to the 140 Mailbox Provider's ARF processing system is not defined by any 141 standards document, but is discussed further in Section 3.2 of 142 [RFC6449]. Policy concerns related to the collection of this 143 data are discussed in Section 3.4 of that document. 144 2. The Mailbox Provider SHOULD process the reports to improve its 145 spam filtering systems. The design of these systems is discussed 146 in [RFC2505] and elsewhere. 147 3. The Mailbox Provider SHOULD send reports to relevant parties who 148 have requested to receive such reports. The reports MUST be 149 formatted per [RFC5965], and transmitted as an email message 150 ([RFC5322]), typically using SMTP ([RFC5321]). The process 151 whereby such parties may request the reports is discussed in 152 Section 3.5 of [RFC6449]. 153 4. The reports SHOULD use "Feedback-Type: abuse", but MAY use other 154 types as appropriate. However, the Mailbox Provider generating 155 the reports SHOULD NOT assume that the operator receiving the 156 reports will treat different Feedback-Types differently. 157 5. The reports SHOULD include the following optional fields whenever 158 practical: Original-Mail-From, Arrival-Date, Source-IP, Original- 159 Rcpt-To. Other optional fields MAY be included, as the 160 implementer feels is appropriate. 161 6. Ongoing maintenance of an ARF processing system is discussed in 162 Section 3.6 of [RFC6449]. 164 7. Receiving and Processing Complaint-Based Solicited Reports 166 1. At the time this document is being written, for the use cases 167 described here, mail operators need to proactively request a 168 stream of ARF reports from Mailbox Providers. Recommendations 169 for preparing to make that request are discussed in Section 4.1 170 of [RFC6449]. 171 2. Mail operators MUST be prepared to receive reports formatted per 172 [RFC5965] as email messages ([RFC5322]) over SMTP ([RFC5321]). 173 These and other types of email messages that may be received are 174 discussed in Section 4.2 of [RFC6449]. 175 3. Mail operators SHOULD utilize an automated system to receive and 176 process these reports, as discussed in Section 4.4 of [RFC6449]. 177 4. That system MUST accept all Feedback-Types defined in [RFC5965] 178 or extensions to it, but implementers SHOULD NOT assume that 179 Mailbox Providers will make use of any Feedback-Type other than 180 "abuse". Additional logic may be required to separate different 181 types of abuse reports after receipt. 182 5. Implementers SHOULD NOT expect all Mailbox Providers to include 183 the same optional fields. 185 6. Actions that mail operators might take upon receiving a report 186 (or multiple reports) are discussed in Section 4.3 of [RFC6449]. 188 8. Generating and Handling Unsolicited Reports 190 Systems that generate unsolicited reports SHOULD ensure that the 191 criteria used to decide what messages to report accurately identify 192 messages that the generating entity believes in good faith are 193 abusive. Criteria might include direct complaint submissions from 194 MUAs, reports triggered by mail sent to "spam trap" or "honeypot" 195 addresses, reports of authentication failures, and virus reports. 196 (These applications might be described in future IETF documents.) 197 Systems SHOULD NOT report all mail sent from a particular sender 198 merely because some of it is determined to be abusive. 200 Senders SHOULD send reports to recipients that are both responsible 201 for the messages and are able to do something about them, and SHOULD 202 NOT send reports to recipients that are uninvolved or only 203 peripherally involved. For example, they SHOULD NOT send reports to 204 the operator of every Autonomous System in the path between the 205 apparent originating system and the operator generating the report. 207 Recipients of unsolicited ARF reports SHOULD, in general, handle them 208 the same way as any other abuse reports. Lacking knowledge about the 209 sender of the report, they SHOULD separate valid from invalid reports 210 by, for example, looking for references to IP ranges, domains, and 211 mailboxes for which the recipient organization is responsible in the 212 copy of the reported message, and by correlating multiple reports of 213 similar messages to identify bulk senders. 215 Some large messaging service providers specifically request that 216 abuse reports be sent to them in ARF format. Experience of systems 217 that send abuse reports in ARF format suggests that even recipient 218 systems that haven't asked for ARF format reports handle them at 219 least as well as any other format such as plain text, with or without 220 a copy of the message attached. 222 9. IANA Considerations 224 [RFC Editor: please remove this section prior to publication.] 226 This document has no IANA actions. 228 10. Security Considerations 230 Implementers are strongly urged to review, at a minimum, the Security 231 Considerations sections of [RFC5965] and [RFC6449]. 233 11. Acknowledgements 235 The author and editor wish to thank John Levine and Alessandro Vesely 236 for their contributions to this memo. 238 All of the Best Practices referenced by this document are found in 239 [RFC6449], written within the Collaboration Committee of the 240 Messaging Anti-Abuse Working Group (MAAWG) -- which is described 241 further in [RFC6449]. 243 Finally, the original author wishes to thank the doctors and staff at 244 the University of Texas MD Anderson Cancer Center for doing what they 245 do. 247 12. References 249 12.1. Normative References 251 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 252 Requirement Levels", BCP 14, RFC 2119, March 1997. 254 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 255 October 2008. 257 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 258 October 2008. 260 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 261 July 2009. 263 [RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An 264 Extensible Format for Email Feedback Reports", RFC 5965, 265 August 2010. 267 12.2. Informative References 269 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 270 STD 53, RFC 1939, May 1996. 272 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 273 3", BCP 9, RFC 2026, October 1996. 275 [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 276 FUNCTIONS", RFC 2142, May 1997. 278 [RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", 279 BCP 30, RFC 2505, February 1999. 281 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 282 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 283 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 285 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 286 4rev1", RFC 3501, March 2003. 288 [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 289 for Authorizing Use of Domains in E-Mail, Version 1", 290 RFC 4408, April 2006. 292 [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 293 Identified Mail (DKIM) Signatures", RFC 6376, 294 September 2011. 296 [RFC6449] Falk, J., "Complaint Feedback Loop Operational 297 Recommendations", RFC 6449, November 2011. 299 Authors' Addresses 301 J.D. Falk 302 Return Path 303 100 Mathilda Street, Suite 100 304 Sunnyvale, CA 94089 305 USA 307 Email: ietf@cybernothing.org 308 URI: http://www.returnpath.net/ 310 M. Kucherawy (editor) 311 Cloudmark 312 128 King St., 2nd Floor 313 San Francisco, CA 94107 314 US 316 Email: msk@cloudmark.com