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