idnits 2.17.1 draft-ietf-marf-as-11.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 2, 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: September 3, 2012 March 2, 2012 8 Creation and Use of Email Feedback Reports: An Applicability Statement 9 for the Abuse Reporting Format (ARF) 10 draft-ietf-marf-as-11 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 September 3, 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 . . . . . 10 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 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 MUST 188 be 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 send reports to relevant parties who 196 have requested to receive such reports. 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 MAY use other 203 types as appropriate. However, the Mailbox Provider generating 204 the reports SHOULD NOT assume that the operator receiving the 205 reports will treat different Feedback-Types differently. 206 2. The reports SHOULD include the following optional fields whenever 207 practical: Original-Mail-From, Arrival-Date, Source-IP, Original- 208 Rcpt-To. Other optional fields MAY be included, as the 209 implementer feels is appropriate. 210 3. Reports MAY be subjected to redaction of user-identifiable data 211 as described in [I-D.IETF-MARF-REDACTION]. 213 5. Receiving and Processing Complaint-Based Solicited Abuse Reports 215 [The numbered items in these subsections are not intended to be in a 216 paricular sequence. The numbers are here during document development 217 to make it easier to identify the items for discussion, and will be 218 removed before publication.] 220 The following subsections include statements applicable when 221 receiving abuse reports in the context of an established abuse report 222 feedback relationship. 224 5.1. General Considerations 226 1. At the time this document is being written, for the use cases 227 described here, mail operators need to proactively request a 228 stream of ARF reports from Mailbox Providers. Recommendations 229 for preparing to make that request are discussed in Section 4.1 230 of [RFC6449]. 232 2. Mail operators MUST be prepared to receive reports formatted per 233 [RFC5965] as email messages ([RFC5322]) over SMTP ([RFC5321]). 234 These and other types of email messages that may be received are 235 discussed in Section 4.2 of [RFC6449]. 236 3. Mail operators need to consider the idea of automating report 237 processing. Discussion of this can be found in Section 4.4 of 238 [RFC6449]. 240 5.2. What To Expect 242 1. An automated report processing system MUST accept all Feedback- 243 Types defined in [RFC5965] or extensions to it, but implementers 244 SHOULD NOT assume that Mailbox Providers will make use of any 245 Feedback-Type other than "abuse". Additional logic may be 246 required to separate different types of abuse reports after 247 receipt. 248 2. Implementers SHOULD NOT expect all Mailbox Providers to include 249 the same optional fields. 250 3. Reports MAY be subjected to redaction of user-identifiable data 251 as described in [I-D.IETF-MARF-REDACTION]. That document also 252 discusses the handling of such reports. This technique is also 253 discussed in Section 4.4 of [RFC6449]. 255 5.3. What To Do 257 1. Actions that mail operators might take upon receiving a report 258 (or multiple reports) are discussed in Section 4.3 of [RFC6449]. 260 6. Generating and Handling Unsolicited Abuse Reports 262 [The numbered items in these subsections are not intended to be in a 263 paricular sequence. The numbers are here during document development 264 to make it easier to identify the items for discussion, and will be 265 removed before publication.] 267 The following subsections include statements applicable when sending 268 or receiving reports outside of the context of an established abuse 269 report feedback relationship. 271 6.1. General Considerations 273 1. A report generator MUST provide a way for a report recipient to 274 request no further reports be sent to that address and MAY 275 provide a way for recipients to change the address(es) to which 276 reports about them are sent. 278 2. Message authentication is generally a good idea, but it is 279 especially important to encourage credibility of and thus 280 response to unsolicited reports. Therefore, as with any other 281 message, report generators sending unsolicited reports SHOULD 282 arrange to send reports for which SPF and/or DKIM checks will 283 pass. 285 6.2. When To Generate Reports 287 1. Handling of unsolicited reports has a significant cost to the 288 receiver. Senders of unsolicited reports, especially those 289 sending large volumes of them automatically, need to be aware of 290 this and do all they reasonably can to avoid sending reports that 291 cannot be used as a basis for action by the recipient, whether 292 this is due to the report being sent about an incident that is 293 not abuse-related, the report being sent to an email address that 294 won't result in action, or the content or format of the report 295 being hard for the recipient to read or use. 296 2. Systems that generate unsolicited reports SHOULD ensure that the 297 criteria used to decide what messages to report accurately 298 identify messages that the reporting entity believes in good 299 faith are abusive. Such criteria might include direct complaint 300 submissions from MUAs, reports triggered by mail sent to "spam 301 trap" or "honeypot" addresses, and virus reports. (These 302 applications might be described in future IETF documents.) 303 3. Systems SHOULD NOT report all mail sent from a particular sender 304 merely because some of it is determined to be abusive. 305 Mechanical reports of mail that "looks like" spam, based solely 306 on the results of inline content analysis tools, SHOULD NOT be 307 sent since, because of their subjective nature, they are unlikely 308 to provide a basis for the recipient to take action. 309 4. If a report generator applies SPF to arriving messages, a report 310 SHOULD NOT be generated to the RFC5321.MailFrom domain if the SPF 311 evaluation produced a "Fail", "SoftFail", "TempError" or 312 "PermError" report, as no reliable assertion or assumption can be 313 made that use of the domain was authorized. A valid exception 314 would be specific knowledge that the SPF result is not definitive 315 for that domain under those circumstances (for example, a message 316 that is also DKIM-signed by the same domain, and that signature 317 validates). 319 6.3. Where To Send Reports 321 1. MUAs SHOULD NOT generate abuse reports directly to entities found 322 in the message or by queries to WHOIS ([RFC3912]) or other 323 heuristic means. Rather, the MUA needs to signal, by some means, 324 the mailbox provider to which it connects to trigger generation 325 of such a report. 327 2. Report generators SHOULD send reports to recipients that are both 328 responsible for the messages and are able to do something about 329 them, and SHOULD NOT send reports to recipients that are 330 uninvolved or only peripherally involved. For example, they 331 SHOULD NOT send reports to the operator of every Autonomous 332 System in the path between the apparent originating system and 333 the operator generating the report. 334 3. Deciding where to send an unsolicited report will typically rely 335 on heuristics. Abuse addresses in WHOIS records of the IP 336 address relaying the subject message and/or of the domain name 337 found in the results of a PTR ("reverse lookup") query on that 338 address are likely reasonable candidates, as is the abuse@domain 339 role address (see [RFC2142]) of related domains. Unsolicited 340 reports SHOULD NOT be sent to email addresses that are not 341 clearly intended to handle abuse reports. Legitimate candidates 342 include those found in WHOIS records or on a web site that either 343 are explicitly described as an abuse contact, or are of the form 344 "abuse@domain". 345 4. Where an abusive message is authenticated using a domain-level 346 authentication technology such as DKIM ([RFC6376]) or SPF 347 ([RFC4408]), the domain that has been verified by the 348 authentication mechanism is often a reasonable candidate for 349 receiving feedback about the message. For DKIM, though, while 350 the authenticated domain has some responsibility for the mail 351 sent, it can be a poor contact point for abuse issues (for 352 example, it could represent the message's author but not its 353 sender, it could identify the bad actor responsible for the 354 message, or it could refer to a domain that cannot receive mail 355 at all). 356 5. Often, unsolicited reports will have no meaning if sent to abuse 357 reporting addresses belonging to the abusive parties themselves. 358 In fact, it is possible that such reports might reveal 359 information about complainants. Reports SHOULD NOT be sent to 360 such addresses if they can be identified beforehand, except where 361 the abusive party is known to be responsive to such reports. 363 6.4. What To Put In Reports 365 1. Reports SHOULD use "Feedback-Type: abuse", but MAY use other 366 types as appropriate. However, the Mailbox Provider generating 367 the reports SHOULD NOT assume that the operator receiving the 368 reports will treat different Feedback-Types differently. 369 2. Reports SHOULD include the following optional fields whenever 370 practical: Original-Mail-From, Arrival-Date, Source-IP, Original- 371 Rcpt-To. Other optional fields MAY be included, as the 372 implementer feels is appropriate. 374 3. Experience suggests use of ARF is advisable in most contexts. 375 Automated recipient systems can handle abuse reports sent in ARF 376 format at least as well as any other format such as plain text, 377 with or without a copy of the message attached. That holds even 378 for systems that did not request ARF format reports, provided 379 that reports are generated with use by recipients not using 380 automated ARF parsing in mind. Anyone sending unsolicited 381 reports in ARF format can legitimately presume that some 382 recipients will only be able to access the human readable (first, 383 text/plain) part of it, and SHOULD include all information needed 384 also in this part. Further, they SHOULD ensure that the report 385 is readable when viewed as plain text, to give low-end ticketing 386 systems as much assistance as possible. Finally, they need to be 387 aware that the report could be discarded or ignored due to 388 failure to take these steps in the most extreme cases. 390 6.5. What To Do With Reports 392 1. Recipients of unsolicited ARF reports SHOULD, in general, handle 393 them the same way as any other abuse reports. However, they MAY 394 take advantage of the standardized parts of the ARF format to 395 automate processing. Lacking knowledge about the sender of the 396 report, they SHOULD separate valid from invalid reports by, for 397 example, looking for references to IP address ranges, domains, 398 and mailboxes for which the recipient organization is responsible 399 in the copy of the reported message, and by correlating multiple 400 reports of similar messages to identify bulk senders. 401 2. Per Section 4.4 of [RFC6449], a network service provider MAY use 402 ARF data for automated forwarding of feedback messages to the 403 originating customer. 404 3. Published abuse mailbox addresses SHOULD NOT reject messages not 405 in the ARF format, as generation of ARF messages can occasionally 406 be unavailable or not applicable. 407 4. Although [RFC6449] suggests that replying to feedback is not 408 useful, in the case of receipt of ARF reports where no feedback 409 arrangement has been established, a non-automated reply might be 410 desirable to indicate what action resulted from the complaint, 411 heading off more severe filtering by the report generator. In 412 addition, using an address that cannot receive replies precludes 413 any requests for additional information, and increases the 414 likelihood that further reports will be discarded or blocked. 415 Thus, a report generator sending unsolicited reports SHOULD 416 ensure that a reply to such a report can be received. Where an 417 unsolicited report results in the establishment of contact with a 418 responsible and responsive party, this can be saved for future 419 complaint handling and possible establishment of a formal 420 (solicited) feedback arrangement. See Section 3.5 of [RFC6449] 421 for a discussion of establishment of feedback arrangements. 423 7. Generating Automatic Authentication Failure Reports 425 [These numbered items are not intended to be in a paricular sequence. 426 The numbers are here during document development to make it easier to 427 identify the items for discussion, and will be removed before 428 publication.] 430 There are some cases where report generation is caused by automation 431 rather than user request. A specific example of this is reporting, 432 using the ARF format (or extensions to it), of messages that fail 433 particular message authentication checks. Examples of this include 434 [I-D.IETF-MARF-DKIM-REPORTING] and [I-D.IETF-MARF-SPF-REPORTING]. 435 The considerations presented below apply in those cases. 437 The applicability statement for this use case is somewhat smaller as 438 many of the issues associated with abuse reports are not relevant to 439 reports about authentication failures. 441 1. Selection of the recipient(s) for reports that are automatically 442 generated MUST be done based on data provided by the report 443 recipient, and MUST NOT be done heuristically. Therefore these 444 reports are always solicited, such as the mechanisms defined in 445 the examples listed above. 446 2. If the message under evaluation by the Verifier is an ARF 447 ([RFC5965]) message, a report MUST NOT be automatically 448 generated. 449 3. When sending a new report via SMTP, it is necessary to construct 450 the message so as to avoid amplification attacks, deliberate or 451 otherwise. The envelope sender address of the report needs to be 452 chosen so that these reports will not generate mail loops. 453 Similar to Section 2 of [RFC3464], the envelope sender address of 454 the report SHOULD be chosen to ensure that no feedback reports 455 will be issued in response to the report itself. Therefore, when 456 an SMTP transaction is used to send a report, the MAIL FROM 457 command SHOULD use the NULL reverse-path, i.e., "MAIL FROM:<>". 458 4. Reports SHOULD use "Feedback-Type: auth-failure", but MAY use 459 other types as appropriate. However, the Mailbox Provider 460 generating the reports SHOULD NOT assume that the operator 461 receiving the reports will treat different Feedback-Types 462 differently. 463 5. Reports SHOULD include the following optional fields whenever 464 practical: Original-Mail-From, Arrival-Date, Source-IP, Original- 465 Rcpt-To. Other optional fields MAY be included, as the 466 implementer feels is appropriate. 468 8. IANA Considerations 470 [RFC Editor: please remove this section prior to publication.] 472 This document has no IANA actions. 474 9. Security Considerations 476 9.1. In Other Documents 478 Implementers are strongly urged to review, at a minimum, the Security 479 Considerations sections of [RFC5965] and [RFC6449]. 481 9.2. Forgeries 483 Report generators that relay user complaints directly, rather than by 484 reference to a stored message (e.g., IMAP or POP), could be duped 485 into sending a complaint about a message that the complaining user 486 never actually received, as an attack on the purported originator of 487 the falsified message. Report generators need to be resilient to 488 such attack methods. 490 Also, these reports may be forged as easily as ordinary Internet 491 electronic mail. User agents and automatic mail handling facilities 492 (such as mail distribution list exploders) that wish to make 493 automatic use of reports of any kind should take appropriate 494 precautions to minimize the potential damage from denial-of-service 495 attacks. 497 Perhaps the simplest means of mitigating this threat is to assert 498 that these reports should themselves be signed with something like 499 DKIM or authorized by SPF. On the other hand, if there is a problem 500 with the DKIM infrastructure at the Verifier, signing DKIM failure 501 reports may produce reports that aren't trusted or even accepted by 502 their intended recipients. Similar issues could exist with SPF 503 evaluation. Use of both technologies can mitigate this risk to a 504 degree. 506 9.3. Amplification Attacks 508 Failure to comply with the recommendations regarding selection of the 509 envelope sender can lead to amplification denial-of-service attacks. 511 9.4. Automatic Generation 513 ARF ([RFC5965]) reports have historically been generated individually 514 as a result of some kind of human request, such as someone clicking a 515 "Report Abuse" button in a mail reader. In contrast, the mechanisms 516 described in some extension documents (i.e., 517 [I-D.IETF-MARF-DKIM-REPORTING] and [I-D.IETF-MARF-SPF-REPORTING]) are 518 focused around automated reporting. This obviously implies the 519 potential for much larger volumes or frequency of messages, and thus 520 greater mail system load (both for report generators and report 521 receivers). 523 Those mechanisms are primarily intended for use in generating reports 524 to aid implementers of DKIM ([RFC6376]), ADSP ([RFC5617]), and SPF 525 ([RFC4408]), and other related protocols during development and 526 debugging. They are not generally intended for prolonged forensic 527 use, specifically because of these load concerns. However, extended 528 use is possible by ADMDs that want to keep a close watch for fraud or 529 infrastructure problems. It is important to consider the impact of 530 doing so on both report generators and the requesting ADMDs. 532 A sender requesting these reports can cause its mail servers to be 533 overwhelmed if it sends out signed messages whose signatures fail to 534 verify for some reason, provoking a large number of reports from 535 report generators. Similarly, a report generator could be 536 overwhelmed by a large volume of messages requesting reports whose 537 signatures fail to validate, as those now need to send reports back 538 to the signer. 540 Limiting the rate of generation of these messages may be appropriate 541 but threatens to inhibit the distribution of important and possibly 542 time-sensitive information. 544 In general ARF feedback loop terms, it is often suggested that report 545 generators only create these (or any) ARF reports after an out-of- 546 band arrangement has been made between two parties. These extension 547 mechanisms then become ways to adjust parameters of an authorized 548 abuse report feedback loop that is configured and activated by 549 private agreement rather than starting to send them automatically 550 based solely on data found in the messages, which may have unintended 551 consequences. 553 9.5. Reporting Multiple Incidents 555 If it is known that a particular host generates abuse reports upon 556 certain incidents, an attacker could forge a high volume of messages 557 that will trigger such a report. The recipient of the report could 558 then be innundated with reports. This could easily be extended to a 559 distributed denial-of-service attack by finding a number of report- 560 generating servers. 562 The incident count referenced in ARF ([RFC5965]) provides a limited 563 form of mitigation. The host generating reports can elect to send 564 reports only periodically, with each report representing a number of 565 identical or nearly-identical incidents. One might even do something 566 inverse-exponentially, sending reports for each of the first ten 567 incidents, then every tenth incident up to 100, then every 100th 568 incident up to 1000, etc., until some period of relative quiet after 569 which the limitation resets. 571 The use of this for "nearly-identical" incidents in particular causes 572 a degradation in reporting quality, however. If for example a large 573 number of pieces of spam arrive from one attacker, a reporting agent 574 could decide only to send a report about a fraction of those 575 messages. While this averts a flood of reports to a system 576 administrator, the precise details of each incident are similarly not 577 sent. 579 Other rate limiting provisions might be considered, including 580 detection of a temporary failure response from the report destination 581 and thus halting report generation to that destination for some 582 period, or simply imposing or negotiating a hard limit on the number 583 of reports to be sent to a particular receiver in a given time frame. 585 10. Acknowledgements 587 The author and editor wish to thank Steve Atkins, John Levine, Shmuel 588 Metz, S. Moonesamy, and Alessandro Vesely for their contributions to 589 this memo. 591 All of the Best Practices referenced by this document are found in 592 [RFC6449], written within the Collaboration Committee of the 593 Messaging Anti-Abuse Working Group (MAAWG). 595 Finally, the original author wishes to thank the doctors and staff at 596 the University of Texas MD Anderson Cancer Center for doing what they 597 do. 599 11. References 601 11.1. Normative References 603 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 604 Requirement Levels", BCP 14, RFC 2119, March 1997. 606 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 607 October 2008. 609 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 610 October 2008. 612 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 613 July 2009. 615 [RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An 616 Extensible Format for Email Feedback Reports", RFC 5965, 617 August 2010. 619 11.2. Informative References 621 [I-D.IETF-MARF-DKIM-REPORTING] 622 Kucherawy, M., "Extensions to DKIM for Failure Reporting", 623 draft-ietf-marf-dkim-reporting (work in progress), 624 January 2012. 626 [I-D.IETF-MARF-REDACTION] 627 Falk, JD. and M. Kucherawy, Ed., "Redaction of Potentially 628 Sensitive Data from Mail Abuse Reports", 629 draft-ietf-marf-redaction (work in progress), March 2011. 631 [I-D.IETF-MARF-SPF-REPORTING] 632 Kitterman, S., "SPF Authentication Failure Reporting using 633 the Abuse Report Format", draft-ietf-marf-spf-reporting 634 (work in progress), January 2012. 636 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 637 STD 53, RFC 1939, May 1996. 639 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 640 3", BCP 9, RFC 2026, October 1996. 642 [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 643 FUNCTIONS", RFC 2142, May 1997. 645 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 646 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 647 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 649 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 650 for Delivery Status Notifications", RFC 3464, 651 January 2003. 653 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 654 4rev1", RFC 3501, March 2003. 656 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 657 September 2004. 659 [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 660 for Authorizing Use of Domains in E-Mail, Version 1", 661 RFC 4408, April 2006. 663 [RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine, 664 "DomainKeys Identified Mail (DKIM) Author Domain Signing 665 Practices (ADSP)", RFC 5617, August 2009. 667 [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 668 Identified Mail (DKIM) Signatures", RFC 6376, 669 September 2011. 671 [RFC6449] Falk, J., "Complaint Feedback Loop Operational 672 Recommendations", RFC 6449, November 2011. 674 Authors' Addresses 676 J.D. Falk 677 Return Path 678 100 Mathilda Street, Suite 100 679 Sunnyvale, CA 94089 680 USA 682 Email: ietf@cybernothing.org 683 URI: http://www.returnpath.net/ 685 M. Kucherawy (editor) 686 Cloudmark 687 128 King St., 2nd Floor 688 San Francisco, CA 94107 689 US 691 Email: msk@cloudmark.com