idnits 2.17.1 draft-ietf-marf-as-12.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 (March 30, 2012) is 4410 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: October 1, 2012 March 30, 2012 8 Creation and Use of Email Feedback Reports: An Applicability Statement 9 for the Abuse Reporting Format (ARF) 10 draft-ietf-marf-as-12 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 Applicability Statement describes common methods for 17 utilizing this format for reporting both abuse and authentication 18 failure events. Mailbox Providers of any size, mail sending 19 entities, and end users can use these methods as a basis to create 20 procedures that best suit them. Some related optional mechanisms are 21 also discussed. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 1, 2012. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Solicited and Unsolicited Reports . . . . . . . . . . . . . . 4 61 4. Creating and Sending Complaint-Based Solicited Abuse 62 Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.1. General Considerations . . . . . . . . . . . . . . . . . . 4 64 4.2. Where To Send Reports . . . . . . . . . . . . . . . . . . 5 65 4.3. What To Put In Reports . . . . . . . . . . . . . . . . . . 5 66 5. Receiving and Processing Complaint-Based Solicited Abuse 67 Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 5.1. General Considerations . . . . . . . . . . . . . . . . . . 5 69 5.2. What To Expect . . . . . . . . . . . . . . . . . . . . . . 6 70 5.3. What To Do . . . . . . . . . . . . . . . . . . . . . . . . 6 71 6. Generating and Handling Unsolicited Abuse Reports . . . . . . 6 72 6.1. General Considerations . . . . . . . . . . . . . . . . . . 6 73 6.2. When To Generate Reports . . . . . . . . . . . . . . . . . 7 74 6.3. Where To Send Reports . . . . . . . . . . . . . . . . . . 7 75 6.4. What To Put In Reports . . . . . . . . . . . . . . . . . . 8 76 6.5. What To Do With Reports . . . . . . . . . . . . . . . . . 9 77 7. Generating Automatic Authentication Failure Reports . . . . . 9 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 80 9.1. In Other Documents . . . . . . . . . . . . . . . . . . . . 11 81 9.2. Forgeries . . . . . . . . . . . . . . . . . . . . . . . . 11 82 9.3. Amplification Attacks . . . . . . . . . . . . . . . . . . 11 83 9.4. Automatic Generation . . . . . . . . . . . . . . . . . . . 11 84 9.5. Reporting Multiple Incidents . . . . . . . . . . . . . . . 12 85 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 88 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 91 1. Introduction 93 The Abuse Reporting Format (ARF) was initially developed for two very 94 specific use cases. Initially, it was intended to be used for 95 reporting feedback between large email operators, or from large email 96 operators to end user network access operators, any of whom could be 97 presumed to have automated abuse-handling systems. Secondarily, it 98 is used by those same large mail operators to send those same reports 99 to other entities, including those involved in sending bulk email for 100 commercial purposes. In either case, the reports would be triggered 101 by direct end user action such as clicking on a "report spam" button 102 in their email client. 104 Though other uses for the format defined in [RFC5965] have been 105 discussed (and may be documented similarly in the future), abuse 106 remains the primary application, with a small amount of adoption of 107 extensions that enable authentication failure reporting. 109 This Applicability Statement provides direction for using the Abuse 110 Reporting Format (ARF) in both contexts. It also includes some 111 statements about the use of ARF in conjunction with other email 112 technologies. 114 The purpose for reporting abusive messages is to stop recurrences. 115 The methods described in this document focus on automating abuse 116 reporting as much as practical, so as to minimize the work of a 117 site's abuse team. There are further reasons why abuse feedback 118 generation is worthwhile, such as instruction of mail filters or 119 reputation trackers, or to initiate investigations of particularly 120 egregious abuses. These other applications are not discussed in this 121 memo. 123 Further introduction to this topic may be found in [RFC6449]. 125 1.1. Discussion 127 [RFC Editor: please remove this section prior to publication.] 129 This document is being discussed within the IETF MARF Working Group, 130 on the marf@ietf.org mailing list. 132 2. Definitions 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119], and are 137 intended to replace the Requirement Levels described in Section 3.3 138 of [RFC2026]. 140 Some of the terminology used in this document is taken from 141 [RFC5598]. 143 "Mailbox Provider" refers to an organization that accepts, stores, 144 and offers access to [RFC5322] messages ("email messages") for end 145 users. Such an organization has typically implemented SMTP 146 ([RFC5321]), and might provide access to messages through IMAP 147 ([RFC3501]), POP ([RFC1939]), a proprietary interface designed for 148 HTTP ([RFC2616]), or a proprietary protocol. 150 3. Solicited and Unsolicited Reports 152 The original application of [RFC5965], and still by far the most 153 common, is when two mail systems make a private agreement to exchange 154 abuse reports, usually reports due to recipients manually reporting 155 messages as spam. We refer to these as solicited reports. 157 Other uses for ARF involve such reports sent between parties that 158 don't know each other. These unsolicited reports are sent without 159 prior arrangement between the parties as to the context and meaning 160 of the reports, so the constraints on how these unsolicited reports 161 need to be structured such that the reports generated are likely to 162 be useful to the recipient, to what address(es) they can usefully be 163 sent, what issues the can be used to report, and how they can be 164 handled by the receiver of the report are very different. 166 4. Creating and Sending Complaint-Based Solicited Abuse Reports 168 [The numbered items in these subsections are not intended to be in a 169 paricular sequence. The numbers are here during document development 170 to make it easier to identify the items for discussion, and will be 171 removed before publication.] 173 The following subsections include statements applicable when 174 establishing an abuse report relationship and generating reports in 175 that context. 177 4.1. General Considerations 179 1. A Mailbox Provider receives reports of abusive or unwanted mail 180 from its users, most often by providing a "report spam" button 181 (or similar nomenclature) in the MUA. The method of transferring 182 this message and any associated metadata from the MUA to the 183 Mailbox Provider's ARF processing system is not defined by any 184 standards document, but is discussed further in Section 3.2 of 185 [RFC6449]. Policy concerns related to the collection of this 186 data are discussed in Section 3.4 of [RFC6449]. 187 2. To implement the recommendations of this memo, the reports are 188 formatted per [RFC5965], and transmitted as an email message 189 ([RFC5322]), typically using SMTP ([RFC5321]). 190 3. Ongoing maintenance of an ARF processing system is discussed in 191 Section 3.6 of [RFC6449]. 193 4.2. Where To Send Reports 195 1. The Mailbox Provider SHOULD NOT send reports to addresses that 196 have not explicitly requested them. The process whereby such 197 parties may request the reports is discussed in Section 3.5 of 198 [RFC6449]. 200 4.3. What To Put In Reports 202 1. The reports SHOULD use "Feedback-Type: abuse", but can use other 203 types as appropriate to the nature of the abuse being reported. 204 However, the Mailbox Provider generating the reports needs to 205 understand that the operator receiving the reports might not 206 treat different feedback types any differently. 207 2. The following fields are optional in [RFC5965], but SHOULD be 208 used in this context when their corresponding values are 209 available: Original-Mail-From, Arrival-Date, Source-IP, Original- 210 Rcpt-To. Other optional fields can be included, as the 211 implementer feels is appropriate. 212 3. User-identifiable data MAY be obscured as described in 213 [I-D.IETF-MARF-REDACTION]. 215 5. Receiving and Processing Complaint-Based Solicited Abuse Reports 217 [The numbered items in these subsections are not intended to be in a 218 paricular sequence. The numbers are here during document development 219 to make it easier to identify the items for discussion, and will be 220 removed before publication.] 222 The following subsections include statements applicable when 223 receiving abuse reports in the context of an established abuse report 224 feedback relationship. 226 5.1. General Considerations 228 1. At the time this document is being written, for the use cases 229 described here, mail operators need to proactively request a 230 stream of ARF reports from Mailbox Providers. Recommendations 231 for preparing to make that request are discussed in Section 4.1 232 of [RFC6449]. 233 2. Furthermore, this document assumes that mail operators exchange 234 abuse reports formatted per ARF [RFC5965] as email messages 235 [RFC5322] over SMTP [RFC5321]. These and other types of email 236 messages that can be received are discussed in Section 4.2 of 237 [RFC6449]. 238 3. Mail operators need to consider the idea of automating report 239 processing. Discussion of this can be found in Section 4.4 of 240 [RFC6449]. 242 5.2. What To Expect 244 1. An automated report processing system MUST accept all Feedback- 245 Types defined in [RFC5965] or extensions to it. However, report 246 receivers cannot assume that Mailbox Providers will make use of 247 any Feedback-Type other than "abuse", except with prior specific 248 knowledge. Additional analysis might be required to separate 249 different types of abuse reports after receipt. 250 2. Implementers SHOULD NOT expect all Mailbox Providers to include 251 the same optional fields. 252 3. Reports may have been subjected to redaction of user-identifiable 253 data as described in [I-D.IETF-MARF-REDACTION]. That document 254 also discusses the handling of such reports. This technique is 255 also discussed in Section 4.4 of [RFC6449]. 257 5.3. What To Do 259 1. Actions that mail operators might take upon receiving a report 260 (or multiple reports) are discussed in Section 4.3 of [RFC6449]. 262 6. Generating and Handling Unsolicited Abuse Reports 264 [The numbered items in these subsections are not intended to be in a 265 paricular sequence. The numbers are here during document development 266 to make it easier to identify the items for discussion, and will be 267 removed before publication.] 269 The following subsections include statements applicable when sending 270 or receiving reports outside of the context of an established abuse 271 report feedback relationship. 273 6.1. General Considerations 275 1. A report generator MUST provide a way for a report recipient to 276 request no further reports be sent to that address and MAY 277 provide a way for recipients to change the address(es) to which 278 reports about them are sent. Details of such mechanisms are 279 outside of the scope of [RFC5965], [RFC6449], and this document. 280 2. Message authentication is generally a good idea, but it is 281 especially important to encourage credibility of and thus 282 response to unsolicited reports. Therefore, as with any other 283 message, report generators sending unsolicited reports SHOULD 284 send reports that will pass SPF and/or DKIM checks. 286 6.2. When To Generate Reports 288 1. Handling of unsolicited reports has a significant cost to the 289 receiver. Senders of unsolicited reports, especially those 290 sending large volumes of them automatically, need to be aware of 291 this and do all they reasonably can to avoid sending reports that 292 cannot be used as a basis for action by the recipient, whether 293 this is due to the report being sent about an incident that is 294 not abuse-related, the report being sent to an email address that 295 won't result in action, or the content or format of the report 296 being hard for the recipient to read or use. 297 2. Systems SHOULD NOT report all mail sent from a particular sender 298 merely because some of it is determined to be abusive. 299 3. Mechanical reports of mail that "looks like" spam, based solely 300 on the results of inline content analysis tools, SHOULD NOT be 301 sent since, because of their subjective nature, they are unlikely 302 to provide a basis for the recipient to take action. Complaints 303 generated by end users about mail that is determined by them to 304 be abusive, or mail delivered to "spam trap" or "honeypot" 305 addresses, are far more likely to be accurate. 306 4. If a report generator applies SPF to arriving messages, a report 307 SHOULD NOT be generated to the RFC5321.MailFrom domain if the SPF 308 evaluation produced a "Fail", "SoftFail", "TempError" or 309 "PermError" report, as no reliable assertion or assumption can be 310 made that use of the domain was authorized. A valid exception 311 would be specific knowledge that the SPF result is not definitive 312 for that domain under those circumstances (for example, a message 313 that is also DKIM-signed by the same domain, and that signature 314 validates). 316 6.3. Where To Send Reports 318 1. MUAs SHOULD NOT generate abuse reports directly to entities 319 merely because they were found in the message, or by queries to 320 WHOIS ([RFC3912]) or other heuristic means. Rather, the MUA 321 needs to signal, by some means, the mailbox provider to which it 322 connects to trigger generation of such a report. 323 2. Report generators SHOULD NOT send reports to recipients that are 324 uninvolved or only peripherally involved. For example, they 325 SHOULD NOT send reports to the operator of every Autonomous 326 System in the path between the apparent originating system and 327 the operator generating the report. Instead, they need to send 328 reports to recipients that are both responsible for the messages 329 and are able to do something about them. 330 3. Deciding where to send an unsolicited report will typically rely 331 on heuristics. Abuse addresses in WHOIS records of the IP 332 address relaying the subject message and/or of the domain name 333 found in the results of a PTR ("reverse lookup") query on that 334 address are likely reasonable candidates, as is the abuse@domain 335 role address (see [RFC2142]) of related domains. Unsolicited 336 reports SHOULD NOT be sent to email addresses that are not 337 clearly intended to handle abuse reports. Legitimate candidates 338 include those found in WHOIS records or on a web site that either 339 are explicitly described as an abuse contact, or are of the form 340 "abuse@domain". 341 4. Where an abusive message is authenticated using a domain-level 342 authentication technology such as DKIM ([RFC6376]) or SPF 343 ([RFC4408]), the domain that has been verified by the 344 authentication mechanism is often a reasonable candidate for 345 receiving feedback about the message. For DKIM, though, while 346 the authenticated domain has some responsibility for the mail 347 sent, it can be a poor contact point for abuse issues (for 348 example, it could represent the message's author but not its 349 sender, it could identify the bad actor responsible for the 350 message, or it could refer to a domain that cannot receive mail 351 at all). 352 5. Often, unsolicited reports will have no meaning if sent to abuse 353 reporting addresses belonging to the abusive parties themselves. 354 In fact, it is possible that such reports might reveal 355 information about complainants. Reports SHOULD NOT be sent to 356 such addresses if they can be identified beforehand, except where 357 the abusive party is known to be responsive to such reports. 359 6.4. What To Put In Reports 361 1. Reports SHOULD use "Feedback-Type: abuse", but can use other 362 types as appropriate. However, the Mailbox Provider generating 363 the reports cannot assume that the operator receiving the reports 364 will treat different Feedback-Types differently. 365 2. Reports SHOULD include the following optional fields whenever 366 their corresponding values are available and applicable to the 367 report: Original-Mail-From, Arrival-Date, Source-IP, Original- 368 Rcpt-To. Other optional fields can be included, as the 369 implementer feels is appropriate. 370 3. Experience suggests use of ARF is advisable in most contexts. 371 Automated recipient systems can handle abuse reports sent in ARF 372 format at least as well as any other format such as plain text, 373 with or without a copy of the message attached. That holds even 374 for systems that did not request ARF format reports, provided 375 that reports are generated with use by recipients not using 376 automated ARF parsing in mind. Anyone sending unsolicited 377 reports in ARF format can legitimately presume that some 378 recipients will only be able to access the human readable (first, 379 text/plain) part of it, and SHOULD include all information needed 380 also in this part. Further, they SHOULD ensure that the report 381 is readable when viewed as plain text, to give low-end ticketing 382 systems as much assistance as possible. Finally, they need to be 383 aware that the report could be discarded or ignored due to 384 failure to take these steps in the most extreme cases. 386 6.5. What To Do With Reports 388 1. Receivers of unsolicited reports can take advantage of the 389 standardized parts of the ARF format to automate processing. 390 Independent of the sender of the report, they can improve 391 processing by separating valid from invalid reports by, for 392 example, looking for references to IP address ranges, domains, 393 and mailboxes for which the recipient organization is responsible 394 in the copy of the reported message, and by correlating multiple 395 reports of similar messages to identify bulk senders. 396 2. Per Section 4.4 of [RFC6449], a network service provider MAY use 397 ARF data for automated forwarding of feedback messages to the 398 originating customer. 399 3. Published abuse mailbox addresses SHOULD NOT reject messages not 400 in the ARF format, as generation of ARF messages can occasionally 401 be unavailable or not applicable. 402 4. Although [RFC6449] suggests that replying to feedback is not 403 useful, in the case of receipt of ARF reports where no feedback 404 arrangement has been established, a non-automated reply might be 405 desirable to indicate what action resulted from the complaint, 406 heading off more severe filtering by the report generator. In 407 addition, using an address that cannot receive replies precludes 408 any requests for additional information, and increases the 409 likelihood that further reports will be discarded or blocked. 410 Thus, a report generator sending unsolicited reports SHOULD NOT 411 generate reports for which a reply cannot be received. Where an 412 unsolicited report results in the establishment of contact with a 413 responsible and responsive party, this can be saved for future 414 complaint handling and possible establishment of a formal 415 (solicited) feedback arrangement. See Section 3.5 of [RFC6449] 416 for a discussion of establishment of feedback arrangements. 418 7. Generating Automatic Authentication Failure Reports 420 [These numbered items are not intended to be in a paricular sequence. 422 The numbers are here during document development to make it easier to 423 identify the items for discussion, and will be removed before 424 publication.] 426 There are some cases where report generation is caused by automation 427 rather than user request. A specific example of this is reporting, 428 using the ARF format (or extensions to it), of messages that fail 429 particular message authentication checks. Examples of this include 430 [I-D.IETF-MARF-DKIM-REPORTING] and [I-D.IETF-MARF-SPF-REPORTING]. 431 The considerations presented below apply in those cases. 433 The applicability statement for this use case is somewhat smaller as 434 many of the issues associated with abuse reports are not relevant to 435 reports about authentication failures. 437 1. Selection of the recipient(s) for reports that are automatically 438 generated MUST be done based on data provided by the report 439 recipient, and MUST NOT be done heuristically. Therefore these 440 reports are always solicited, such as the mechanisms defined in 441 the examples listed above. 442 2. If the message under evaluation by the Verifier is an ARF 443 ([RFC5965]) message, a report MUST NOT be automatically 444 generated. 445 3. When sending a new report via SMTP, it is necessary to construct 446 the message so as to avoid amplification attacks, deliberate or 447 otherwise. The envelope sender address of the report needs to be 448 chosen so that these reports will not generate mail loops. 449 Similar to Section 2 of [RFC3464], the envelope sender address of 450 the report needs to be chosen to ensure that no feedback reports 451 will be issued in response to the report itself. Therefore, when 452 an SMTP transaction is used to send a report, the MAIL FROM 453 command SHOULD use the NULL reverse-path, i.e., "MAIL FROM:<>". 454 4. Reports SHOULD use "Feedback-Type: auth-failure", but MAY use 455 other types as appropriate. However, the Mailbox Provider 456 generating the reports cannot assume that the operator receiving 457 the reports will treat different Feedback-Types differently. 458 5. These reports SHOULD include the following optional fields, 459 although they are optional in [RFC5965], whenever their 460 corresponding values are available: Original-Mail-From, Arrival- 461 Date, Source-IP, Original-Rcpt-To. Other optional fields can be 462 included, as the implementer feels is appropriate. 464 8. IANA Considerations 466 [RFC Editor: please remove this section prior to publication.] 468 This document has no IANA actions. 470 9. Security Considerations 472 9.1. In Other Documents 474 Implementers are strongly urged to review, at a minimum, the Security 475 Considerations sections of [RFC5965] and [RFC6449]. 477 9.2. Forgeries 479 Report generators that relay user complaints directly, rather than by 480 reference to a stored message (e.g., IMAP or POP), could be duped 481 into sending a complaint about a message that the complaining user 482 never actually received, as an attack on the purported originator of 483 the falsified message. Report generators need to be resilient to 484 such attack methods. 486 Also, these reports may be forged as easily as ordinary Internet 487 electronic mail. User agents and automatic mail handling facilities 488 (such as mail distribution list exploders) that wish to make 489 automatic use of reports of any kind should take appropriate 490 precautions to minimize the potential damage from denial-of-service 491 attacks. 493 Perhaps the simplest means of mitigating this threat is to assert 494 that these reports should themselves be signed with something like 495 DKIM or authorized by SPF. On the other hand, if there is a problem 496 with the DKIM infrastructure at the Verifier, signing DKIM failure 497 reports may produce reports that aren't trusted or even accepted by 498 their intended recipients. Similar issues could exist with SPF 499 evaluation. Use of both technologies can mitigate this risk to a 500 degree. 502 9.3. Amplification Attacks 504 Failure to comply with the recommendations regarding selection of the 505 envelope sender can lead to amplification denial-of-service attacks. 507 9.4. Automatic Generation 509 ARF ([RFC5965]) reports have historically been generated individually 510 as a result of some kind of human request, such as someone clicking a 511 "Report Abuse" button in a mail reader. In contrast, the mechanisms 512 described in some extension documents (i.e., 513 [I-D.IETF-MARF-DKIM-REPORTING] and [I-D.IETF-MARF-SPF-REPORTING]) are 514 focused around automated reporting. This obviously implies the 515 potential for much larger volumes or frequency of messages, and thus 516 greater mail system load (both for report generators and report 517 receivers). 519 Those mechanisms are primarily intended for use in generating reports 520 to aid implementers of DKIM ([RFC6376]), ADSP ([RFC5617]), and SPF 521 ([RFC4408]), and other related protocols during development and 522 debugging. They are not generally intended for prolonged forensic 523 use, specifically because of these load concerns. However, extended 524 use is possible by ADMDs that want to keep a close watch for fraud or 525 infrastructure problems. It is important to consider the impact of 526 doing so on both report generators and the requesting ADMDs. 528 A sender requesting these reports can cause its mail servers to be 529 overwhelmed if it sends out signed messages whose signatures fail to 530 verify for some reason, provoking a large number of reports from 531 report generators. Similarly, a report generator could be 532 overwhelmed by a large volume of messages requesting reports whose 533 signatures fail to validate, as those now need to send reports back 534 to the signer. 536 Limiting the rate of generation of these messages may be appropriate 537 but threatens to inhibit the distribution of important and possibly 538 time-sensitive information. 540 In general ARF feedback loop terms, it is often suggested that report 541 generators only create these (or any) ARF reports after an out-of- 542 band arrangement has been made between two parties. These extension 543 mechanisms then become ways to adjust parameters of an authorized 544 abuse report feedback loop that is configured and activated by 545 private agreement rather than starting to send them automatically 546 based solely on data found in the messages, which may have unintended 547 consequences. 549 9.5. Reporting Multiple Incidents 551 If it is known that a particular host generates abuse reports upon 552 certain incidents, an attacker could forge a high volume of messages 553 that will trigger such a report. The recipient of the report could 554 then be innundated with reports. This could easily be extended to a 555 distributed denial-of-service attack by finding a number of report- 556 generating servers. 558 The incident count referenced in ARF ([RFC5965]) provides a limited 559 form of mitigation. The host generating reports can elect to send 560 reports only periodically, with each report representing a number of 561 identical or nearly-identical incidents. One might even do something 562 inverse-exponentially, sending reports for each of the first ten 563 incidents, then every tenth incident up to 100, then every 100th 564 incident up to 1000, etc., until some period of relative quiet after 565 which the limitation resets. 567 The use of this for "nearly-identical" incidents in particular causes 568 a degradation in reporting quality, however. If for example a large 569 number of pieces of spam arrive from one attacker, a reporting agent 570 could decide only to send a report about a fraction of those 571 messages. While this averts a flood of reports to a system 572 administrator, the precise details of each incident are similarly not 573 sent. 575 Other rate limiting provisions might be considered, including 576 detection of a temporary failure response from the report destination 577 and thus halting report generation to that destination for some 578 period, or simply imposing or negotiating a hard limit on the number 579 of reports to be sent to a particular receiver in a given time frame. 581 10. Acknowledgements 583 The author and editor wish to thank Steve Atkins, John Levine, Shmuel 584 Metz, S. Moonesamy, and Alessandro Vesely for their contributions to 585 this memo. 587 All of the Best Practices referenced by this document are found in 588 [RFC6449], written within the Collaboration Committee of the 589 Messaging Anti-Abuse Working Group (MAAWG). 591 Finally, the original author wishes to thank the doctors and staff at 592 the University of Texas MD Anderson Cancer Center for doing what they 593 do. 595 11. References 597 11.1. Normative References 599 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 600 Requirement Levels", BCP 14, RFC 2119, March 1997. 602 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 603 October 2008. 605 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 606 October 2008. 608 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 609 July 2009. 611 [RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An 612 Extensible Format for Email Feedback Reports", RFC 5965, 613 August 2010. 615 11.2. Informative References 617 [I-D.IETF-MARF-DKIM-REPORTING] 618 Kucherawy, M., "Extensions to DKIM for Failure Reporting", 619 draft-ietf-marf-dkim-reporting (work in progress), 620 January 2012. 622 [I-D.IETF-MARF-REDACTION] 623 Falk, JD. and M. Kucherawy, Ed., "Redaction of Potentially 624 Sensitive Data from Mail Abuse Reports", 625 draft-ietf-marf-redaction (work in progress), March 2011. 627 [I-D.IETF-MARF-SPF-REPORTING] 628 Kitterman, S., "SPF Authentication Failure Reporting using 629 the Abuse Report Format", draft-ietf-marf-spf-reporting 630 (work in progress), January 2012. 632 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 633 STD 53, RFC 1939, May 1996. 635 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 636 3", BCP 9, RFC 2026, October 1996. 638 [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 639 FUNCTIONS", RFC 2142, May 1997. 641 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 642 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 643 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 645 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 646 for Delivery Status Notifications", RFC 3464, 647 January 2003. 649 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 650 4rev1", RFC 3501, March 2003. 652 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 653 September 2004. 655 [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 656 for Authorizing Use of Domains in E-Mail, Version 1", 657 RFC 4408, April 2006. 659 [RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine, 660 "DomainKeys Identified Mail (DKIM) Author Domain Signing 661 Practices (ADSP)", RFC 5617, August 2009. 663 [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 664 Identified Mail (DKIM) Signatures", RFC 6376, 665 September 2011. 667 [RFC6449] Falk, J., "Complaint Feedback Loop Operational 668 Recommendations", RFC 6449, November 2011. 670 Authors' Addresses 672 J.D. Falk 673 Return Path 674 100 Mathilda Street, Suite 100 675 Sunnyvale, CA 94089 676 USA 678 Email: ietf@cybernothing.org 679 URI: http://www.returnpath.net/ 681 M. Kucherawy (editor) 682 Cloudmark 683 128 King St., 2nd Floor 684 San Francisco, CA 94107 685 US 687 Email: msk@cloudmark.com