idnits 2.17.1 draft-ietf-marf-as-05.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 (January 31, 2012) is 4469 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: August 3, 2012 January 31, 2012 8 Creation and Use of Email Feedback Reports: An Applicability Statement 9 for the Abuse Reporting Format (ARF) 10 draft-ietf-marf-as-05 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 August 3, 2012. 38 Copyright Notice 40 Copyright (c) 2012 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, or caused by anything else that the sender of the report 126 considers to merit an abuse report. Abuse addresses in WHOIS records 127 of the source IP and of the domain found in the results of a PTR 128 ("reverse lookup") query on that address are likely reasonable 129 candidates for receiving feedback about the message, although 130 automated parsing may be difficult, and such addresses are not 131 guaranteed to be useful. 133 However, it is inadvisable to generate automated reports based on 134 inline content analysis tools that apply subjective evaluation rules. 135 This can cause reports that, because of their subjective nature, are 136 not actionable by report receivers, which wastes valuable operator 137 time in processing them. 139 6. Creating and Sending Complaint-Based Solicited Reports 141 1. A Mailbox Provider receives reports of abusive or unwanted mail 142 from its users, most often by providing a "report spam" button 143 (or similar nomenclature) in the MUA. The method of transferring 144 this message and any associated metadata from the MUA to the 145 Mailbox Provider's ARF processing system is not defined by any 146 standards document, but is discussed further in Section 3.2 of 147 [RFC6449]. Policy concerns related to the collection of this 148 data are discussed in Section 3.4 of [RFC6449]. 149 2. The Mailbox Provider SHOULD process the reports to improve its 150 spam filtering systems. The design of these systems is discussed 151 in [RFC2505] and elsewhere. 152 3. The Mailbox Provider SHOULD send reports to relevant parties who 153 have requested to receive such reports. The reports MUST be 154 formatted per [RFC5965], and transmitted as an email message 155 ([RFC5322]), typically using SMTP ([RFC5321]). The process 156 whereby such parties may request the reports is discussed in 157 Section 3.5 of [RFC6449]. 158 4. The reports SHOULD use "Feedback-Type: abuse", but MAY use other 159 types as appropriate. However, the Mailbox Provider generating 160 the reports SHOULD NOT assume that the operator receiving the 161 reports will treat different Feedback-Types differently. 162 5. The reports SHOULD include the following optional fields whenever 163 practical: Original-Mail-From, Arrival-Date, Source-IP, Original- 164 Rcpt-To. Other optional fields MAY be included, as the 165 implementer feels is appropriate. 166 6. Ongoing maintenance of an ARF processing system is discussed in 167 Section 3.6 of [RFC6449]. 168 7. Reports MAY be subjected to redaction of user-identifiable data 169 as described in [I-D.IETF-MARF-REDACTION]. 171 7. Receiving and Processing Complaint-Based Solicited Reports 173 1. At the time this document is being written, for the use cases 174 described here, mail operators need to proactively request a 175 stream of ARF reports from Mailbox Providers. Recommendations 176 for preparing to make that request are discussed in Section 4.1 177 of [RFC6449]. 178 2. Mail operators MUST be prepared to receive reports formatted per 179 [RFC5965] as email messages ([RFC5322]) over SMTP ([RFC5321]). 180 These and other types of email messages that may be received are 181 discussed in Section 4.2 of [RFC6449]. 182 3. Mail operators need to consider the idea of automating report 183 processing. Discussion of this can be found in Section 4.4 of 184 [RFC6449]. 186 4. An automated report processing system MUST accept all Feedback- 187 Types defined in [RFC5965] or extensions to it, but implementers 188 SHOULD NOT assume that Mailbox Providers will make use of any 189 Feedback-Type other than "abuse". Additional logic may be 190 required to separate different types of abuse reports after 191 receipt. 192 5. Implementers SHOULD NOT expect all Mailbox Providers to include 193 the same optional fields. 194 6. Actions that mail operators might take upon receiving a report 195 (or multiple reports) are discussed in Section 4.3 of [RFC6449]. 196 7. Reports MAY be subjected to redaction of user-identifiable data 197 as described in [I-D.IETF-MARF-REDACTION]. This is also 198 discussed in Section 4.4 of [RFC6449]. Although the end user 199 causing the report to be generated has been obscured, the report 200 processor SHOULD attempt to correlate and prioritize reports that 201 appear to have been caused by the same end user as it may be 202 indicative of a problem worthy of increased attention. 204 8. Generating and Handling Unsolicited Reports 206 1. Systems that generate unsolicited reports SHOULD ensure that the 207 criteria used to decide what messages to report accurately 208 identify messages that the reporting entity believes in good 209 faith are abusive. Such criteria might include direct complaint 210 submissions from MUAs, reports triggered by mail sent to "spam 211 trap" or "honeypot" addresses, reports of authentication 212 failures, and virus reports. (These applications might be 213 described in future IETF documents.) Systems SHOULD NOT report 214 all mail sent from a particular sender merely because some of it 215 is determined to be abusive. 216 2. With respect to authentication failures, these could occur for 217 legitimate reasons outside of the control of the author. A 218 report generator SHOULD be cautious to generate reports only in 219 those cases where doing so highlights a serious problem, such as 220 an ADSP ([RFC5617]) failure for a high-value spam target. 221 3. MUAs SHOULD NOT generate abuse reports directly to entities 222 found in the message or by queries to WHOIS or other heuristic 223 means. Rather, the MUA should signal, by some means, the 224 mailbox provider to which it connects to generate such a report. 225 4. Report generators SHOULD send reports to recipients that are 226 both responsible for the messages and are able to do something 227 about them, and SHOULD NOT send reports to recipients that are 228 uninvolved or only peripherally involved. For example, they 229 SHOULD NOT send reports to the operator of every Autonomous 230 System in the path between the apparent originating system and 231 the operator generating the report. 233 5. Where an abusive message is signed using a domain-level 234 authentication technology such as DKIM ([RFC6376]) or SPF 235 ([RFC4408]), the domain that has been verified by the 236 authentication mechanism is likely a reasonable candidate for 237 receiving feedback about the message. However, this is not 238 universally true, since sometimes the domain thus verified 239 exists only to distinguish one stream of mail from another (see 240 Section 2.5 of [RFC6377]), and cannot actually receive email. 241 6. Recipients of unsolicited ARF reports SHOULD, in general, handle 242 them the same way as any other abuse reports. However, they MAY 243 take advantage of the standardized parts of the ARF format to 244 automate processing. Lacking knowledge about the sender of the 245 report, they SHOULD separate valid from invalid reports by, for 246 example, looking for references to IP ranges, domains, and 247 mailboxes for which the recipient organization is responsible in 248 the copy of the reported message, and by correlating multiple 249 reports of similar messages to identify bulk senders. 250 7. Reports SHOULD use "Feedback-Type: abuse", but MAY use other 251 types as appropriate. However, the Mailbox Provider generating 252 the reports SHOULD NOT assume that the operator receiving the 253 reports will treat different Feedback-Types differently. 254 8. Reports SHOULD include the following optional fields whenever 255 practical: Original-Mail-From, Arrival-Date, Source-IP, 256 Original-Rcpt-To. Other optional fields MAY be included, as the 257 implementer feels is appropriate. 258 9. Per Section 4.4 of [RFC6449], a network service provider MAY use 259 ARF data for automated forwarding of feedabck messages to the 260 originating customer. 261 10. Published abuse mailbox addresses SHOULD NOT reject messages not 262 in the ARF format, as generation of ARF messages can 263 occasionally be unavailable or not applicable. Nevertheless, 264 some large messaging service providers specifically request that 265 abuse reports be sent to them in ARF format. Experience of 266 systems that send abuse reports in ARF format suggests that even 267 automated recipient systems that haven't asked for ARF format 268 reports handle them at least as well as any other format such as 269 plain text, with or without a copy of the message attached. 270 This suggests use of ARF is advisable in most contexts. 271 11. This is, however, not universally true. Anyone sending 272 unsolicited reports in ARF format can legitimately presume that 273 recipients will not be able to see the ARF metadata (i.e., those 274 elements present in the second part of the report), and instead 275 MAY include all information needed in the human readable (first, 276 text/plain) section of the report. Further, they MAY ensure 277 that the report is readable when viewed as plain text, to give 278 low-end ticketing systems as much assistance as possible. 279 Finally, they need to be aware that the report could be 280 discarded or ignored due to failure to take these steps in the 281 most extreme cases. 282 12. Although [RFC6449] suggests that replying to feedback is not 283 useful, in the case of receipt of ARF reports where no feedback 284 arrangement has been established, a reply might be desirable to 285 indicate that the complaint will result in action, heading off 286 more severe filtering from the report generator. Thus, a report 287 generator sending unsolicited reports SHOULD ensure that a reply 288 to such a report can be received. Where an unsolicited report 289 results in the establishment of contact with a responsible and 290 responsive party, this can be saved for future complaint 291 handling and possible establishment of a formal (solicited) 292 feedback arrangement. See Section 3.5 of [RFC6449] for a 293 discussion of establishment of feedback arrangements. 294 13. Unsolicited reports will have no meaning if sent to abuse 295 reporting addresses belonging to the abusive parties themselves. 296 Reports SHOULD NOT be sent to such addresses if they can be 297 identified beforehand. 299 9. IANA Considerations 301 [RFC Editor: please remove this section prior to publication.] 303 This document has no IANA actions. 305 10. Security Considerations 307 Implementers are strongly urged to review, at a minimum, the Security 308 Considerations sections of [RFC5965] and [RFC6449]. 310 Report generators that relay user complaints directly, rather than by 311 reference to a stored message (e.g., IMAP or POP), could be duped 312 into sending a complaint about a message that the complaining user 313 never actually received, as an attack on the purported originator of 314 the falsified message. Report generators need to be resilient to 315 such attack methods. 317 11. Acknowledgements 319 The author and editor wish to thank Steve Atkins, John Levine, Shmuel 320 Metz, and Alessandro Vesely for their contributions to this memo. 322 All of the Best Practices referenced by this document are found in 323 [RFC6449], written within the Collaboration Committee of the 324 Messaging Anti-Abuse Working Group (MAAWG). 326 Finally, the original author wishes to thank the doctors and staff at 327 the University of Texas MD Anderson Cancer Center for doing what they 328 do. 330 12. References 332 12.1. Normative References 334 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 335 Requirement Levels", BCP 14, RFC 2119, March 1997. 337 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 338 October 2008. 340 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 341 October 2008. 343 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 344 July 2009. 346 [RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An 347 Extensible Format for Email Feedback Reports", RFC 5965, 348 August 2010. 350 12.2. Informative References 352 [I-D.IETF-MARF-REDACTION] 353 Falk, JD. and M. Kucherawy, Ed., "Redaction of Potentially 354 Sensitive Data from Mail Abuse Reports", 355 I-D draft-ietf-marf-redaction, March 2011. 357 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 358 STD 53, RFC 1939, May 1996. 360 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 361 3", BCP 9, RFC 2026, October 1996. 363 [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 364 FUNCTIONS", RFC 2142, May 1997. 366 [RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", 367 BCP 30, RFC 2505, February 1999. 369 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 370 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 371 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 373 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 374 4rev1", RFC 3501, March 2003. 376 [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 377 for Authorizing Use of Domains in E-Mail, Version 1", 378 RFC 4408, April 2006. 380 [RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine, 381 "DomainKeys Identified Mail (DKIM) Author Domain Signing 382 Practices (ADSP)", RFC 5617, August 2009. 384 [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 385 Identified Mail (DKIM) Signatures", RFC 6376, 386 September 2011. 388 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and 389 Mailing Lists", BCP 167, RFC 6377, September 2011. 391 [RFC6449] Falk, J., "Complaint Feedback Loop Operational 392 Recommendations", RFC 6449, November 2011. 394 Authors' Addresses 396 J.D. Falk 397 Return Path 398 100 Mathilda Street, Suite 100 399 Sunnyvale, CA 94089 400 USA 402 Email: ietf@cybernothing.org 403 URI: http://www.returnpath.net/ 405 M. Kucherawy (editor) 406 Cloudmark 407 128 King St., 2nd Floor 408 San Francisco, CA 94107 409 US 411 Email: msk@cloudmark.com