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