idnits 2.17.1 draft-ietf-marf-as-16.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 25, 2012) is 4376 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 27, 2012 April 25, 2012 8 Creation and Use of Email Feedback Reports: An Applicability Statement 9 for the Abuse Reporting Format (ARF) 10 draft-ietf-marf-as-16 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 27, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Solicited and Unsolicited Reports . . . . . . . . . . . . . . 4 61 4. Generating And Handling Solicited Abuse Reports . . . . . . . 4 62 4.1. General Considerations for Feedback Providers . . . . . . 5 63 4.2. Where To Send Reports . . . . . . . . . . . . . . . . . . 5 64 4.3. What To Put In Reports . . . . . . . . . . . . . . . . . . 5 65 4.4. General Considerations for Feedback Consumers . . . . . . 5 66 4.5. What To Expect . . . . . . . . . . . . . . . . . . . . . . 6 67 4.6. What To Do With Reports . . . . . . . . . . . . . . . . . 6 68 5. Generating and Handling Unsolicited Abuse Reports . . . . . . 6 69 5.1. General Considerations . . . . . . . . . . . . . . . . . . 6 70 5.2. When To Generate Reports . . . . . . . . . . . . . . . . . 7 71 5.3. Where To Send Reports . . . . . . . . . . . . . . . . . . 7 72 5.4. What To Put In Reports . . . . . . . . . . . . . . . . . . 8 73 5.5. What To Do With Reports . . . . . . . . . . . . . . . . . 9 74 6. Generating Automatic Authentication Failure Reports . . . . . 10 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 8.1. In Other Documents . . . . . . . . . . . . . . . . . . . . 11 78 8.2. Forgeries . . . . . . . . . . . . . . . . . . . . . . . . 11 79 8.3. Amplification Attacks . . . . . . . . . . . . . . . . . . 11 80 8.4. Automatic Generation . . . . . . . . . . . . . . . . . . . 12 81 8.5. Reporting Multiple Incidents . . . . . . . . . . . . . . . 12 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 85 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 88 1. Introduction 90 The Abuse Reporting Format (ARF) was initially developed for two very 91 specific use cases. Initially, it was intended to be used for 92 reporting feedback between large email operators, or from large email 93 operators to end user network access operators, any of whom could be 94 presumed to have automated abuse-handling systems. Secondarily, it 95 is used by those same large mail operators to send those same reports 96 to other entities, including those involved in sending bulk email for 97 commercial purposes. In either case, the reports would be triggered 98 by direct end user action such as clicking on a "report spam" button 99 in their email client. 101 Though other uses for the ARF format defined in [RFC5965] have been 102 discussed (and may be documented similarly in the future), abuse 103 remains the primary application, with a small amount of adoption of 104 extensions that enable authentication failure reporting. 106 This Applicability Statement provides direction for using the Abuse 107 Reporting Format (ARF) in both contexts. It also includes some 108 statements about the use of ARF in conjunction with other email 109 technologies. 111 The purpose for reporting abusive messages is to stop recurrences. 112 The methods described in this document focus on automating abuse 113 reporting as much as practical, so as to minimize the work of a 114 site's abuse team. There are further reasons why abuse feedback 115 generation is worthwhile, such as instruction of mail filters or 116 reputation trackers, or to initiate investigations of particularly 117 egregious abuses. These other applications are not discussed in this 118 memo. 120 Further introduction to this topic may be found in [RFC6449], which 121 is effectively an Applicability Statement written outside of the IETF 122 and thus never achieved IETF consensus. Much of the content for that 123 document was input to this one. 125 At the time of publication of this document, five feedback types are 126 registered. This document only discusses two of them ("abuse" and 127 "auth-failure") as they are seeing sufficient use in practice that 128 applicability statements can be made about them. The others, i.e., 129 "fraud" [RFC5965] and "not-spam" [RFC6430], are either too new or too 130 seldomly used to be included here. 132 1.1. Discussion 134 [RFC Editor: please remove this section prior to publication.] 135 This document is being discussed within the IETF MARF Working Group, 136 on the marf@ietf.org mailing list. 138 2. Definitions 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119], and are 143 intended to replace the Requirement Levels described in Section 3.3 144 of [RFC2026]. 146 Some of the terminology used in this document is taken from 147 [RFC5598]. 149 "Mailbox Provider" refers to an organization that accepts, stores, 150 and offers access to [RFC5322] messages ("email messages") for end 151 users. Such an organization has typically implemented SMTP 152 ([RFC5321]), and might provide access to messages through IMAP 153 ([RFC3501]), POP ([RFC1939]), a proprietary interface designed for 154 HTTP ([RFC2616]), or a proprietary protocol. 156 3. Solicited and Unsolicited Reports 158 The original application of [RFC5965], and still by far the most 159 common, is when two mail systems make a private agreement to exchange 160 abuse reports, usually reports due to recipients manually reporting 161 messages as spam. We refer to these as solicited reports. 163 Other uses for ARF involve such reports sent between parties that 164 don't know each other. These unsolicited reports are sent without 165 prior arrangement between the parties as to the context and meaning 166 of the reports, so the constraints on how these unsolicited reports 167 need to be structured such that the reports generated are likely to 168 be useful to the recipient, to what address(es) they can usefully be 169 sent, what issues the can be used to report, and how they can be 170 handled by the receiver of the report are very different. 172 The two cases are covered separately in following sections. 174 4. Generating And Handling Solicited Abuse Reports 176 [The numbered items in these subsections are not intended to be in a 177 paricular sequence. The numbers are here during document development 178 to make it easier to identify the items for discussion, and will be 179 removed before publication.] 181 4.1. General Considerations for Feedback Providers 183 1. A Mailbox Provider receives reports of abusive or unwanted mail 184 from its users, most often by providing a "report spam" button 185 (or similar nomenclature) in the MUA (Mail User Agent). The 186 method of transferring this message and any associated metadata 187 from the MUA to the Mailbox Provider's ARF processing system is 188 not defined by any standards document, but is discussed further 189 in Section 3.2 of [RFC6449]. Policy concerns related to the 190 collection of this data are discussed in Section 3.4 of 191 [RFC6449]. 192 2. To implement the recommendations of this memo, the reports are 193 formatted per [RFC5965], and transmitted as an email message 194 ([RFC5322]), typically using SMTP ([RFC5321]). 195 3. Ongoing maintenance of an ARF processing system is discussed in 196 Section 3.6 of [RFC6449]. 198 4.2. Where To Send Reports 200 1. The Mailbox Provider SHOULD NOT send reports to addresses that 201 have not explicitly requested them. A valid deviation might be 202 the result of local policy instructions. The process whereby 203 such parties may request the reports is discussed in Section 3.5 204 of [RFC6449]. 206 4.3. What To Put In Reports 208 1. The reports SHOULD use "Feedback-Type: abuse", for its type. 209 Although a Mailbox Provider generating the reports can use other 210 types appropriate to the nature of the abuse being reported, the 211 operator receiving the reports might not treat different feedback 212 types differently. 213 2. The following fields are optional in [RFC5965], but SHOULD be 214 used in this context when their corresponding values are 215 available: Original-Mail-From, Arrival-Date, Source-IP, Original- 216 Rcpt-To. Other optional fields can be included, as the 217 implementer feels is appropriate. 218 3. User-identifiable data MAY be obscured as described in [RFC6590]. 220 4.4. General Considerations for Feedback Consumers 222 1. ARF report streams are established proactively between Feedback 223 Providers and Feedback Consumers. Recommendations for preparing 224 to make that request are discussed in Section 4.1 of [RFC6449]. 225 2. Operators MUST be able to accept ARF [RFC5965] reports as email 226 messages [RFC5322] over SMTP [RFC5321]. These and other types of 227 email messages that can be received are discussed in Section 4.2 228 of [RFC6449]. 230 3. Recipients of feedback reports that are part of formal feedback 231 arrangements have to be capable of handling large volumes of 232 reports. This could require automation of report processing. 233 Discussion of this can be found in Section 4.4 of [RFC6449]. 235 4.5. What To Expect 237 1. The list of vaild Feedback-Types is defined in [RFC5965], which 238 created an IANA registry for valid values to allow for 239 extensions. However, an automated report processing system MUST 240 NOT reject (in the SMTP sense) a report based solely on an 241 unknown Feedback-Type, to allow for handling of new types that 242 are not yet supported. The automated system can simply set 243 reports of unknown types aside for manual handling. However, 244 Mailbox Providers might only make use of the "abuse" Feedback- 245 Type. Therefore, report receivers might be required to do 246 additional analysis to separate different types of abuse reports 247 after receipt if they do not have prior specific knowledge of the 248 sender of the report. 249 2. Reports receivers MUST accept reports that have obscured their 250 user-identifiable data as described in [RFC6590]. That document 251 also discusses the handling of such reports. This technique is 252 also discussed in Section 4.4 of [RFC6449]. 254 4.6. What To Do With Reports 256 1. Section 4.3 of [RFC6449] discusses actions that mail operators 257 might take upon receiving a report (or multiple reports). 259 5. Generating and Handling Unsolicited Abuse Reports 261 [The numbered items in these subsections are not intended to be in a 262 paricular sequence. The numbers are here during document development 263 to make it easier to identify the items for discussion, and will be 264 removed before publication.] 266 5.1. General Considerations 268 1. It is essential for report recipients to be capable of throttling 269 reports being sent to avoid damage to their own installations. 270 Therefore, Feedback Providers MUST provide a way for report 271 recipients to request that no further reports be sent. 272 Unfortunately, no standardized mechanism for such requests exists 273 to date, and all existing mechanisms for meeting this requirement 274 are out-of-band. 276 2. Message authentication is generally a good idea, but it is 277 especially important to encourage credibility of and thus 278 response to unsolicited reports. Therefore, as with any other 279 message, Feedback Providers sending unsolicited reports SHOULD 280 send reports that they believe will pass Sender Policy Framework 281 ([RFC4408]) and/or DomainKeys Identified Mail ([RFC6376]) checks. 283 5.2. When To Generate Reports 285 1. Handling of unsolicited reports has a significant cost to the 286 report receiver. Senders of unsolicited reports, especially 287 those sending large volumes of them automatically SHOULD NOT send 288 reports that cannot be used as a basis for action by the 289 recipient, whether this is due to the report being sent about an 290 incident that is not abuse-related, the report being sent to an 291 email address that won't result in action, or the content or 292 format of the report being hard for the recipient to read or use. 293 2. Feedback Providers SHOULD NOT report all mail sent from a 294 particular sender merely because some of it is determined to be 295 abusive. 296 3. Mechanical reports of mail that "looks like" spam, based solely 297 on the results of inline content analysis tools, SHOULD NOT be 298 sent since, because of their subjective nature, they are unlikely 299 to provide a basis for the recipient to take action. Complaints 300 generated by end users about mail that is determined by them to 301 be abusive, or mail delivered to "spam trap" or "honeypot" 302 addresses, are far more likely to be accurate and MAY be sent. 303 4. If a Feedback Provider applies the Sender Policy Framework 304 [RFC4408] to arriving messages, a report SHOULD NOT be generated 305 to the RFC5321.MailFrom domain if the SPF evaluation produced a 306 "Fail", "SoftFail", "TempError" or "PermError" report, as no 307 reliable assertion or assumption can be made that use of the 308 domain was authorized. A valid exception would be specific 309 knowledge that the SPF result is not definitive for that domain 310 under those circumstances (for example, a message that is also 311 signed using DomainKeys Identified Mail (DKIM, [RFC6376]) by the 312 same domain, and that signature validates). 314 5.3. Where To Send Reports 316 1. Rather than generating feedback reports themselves, MUAs SHOULD 317 make abuse reports back to their mailbox providers so that they 318 can generate and send ARF messages on behalf of end users (see 319 Section 3.2 of [RFC6449]). This allows centralized processing 320 and tracking of reports, and provides training input to filtering 321 systems. There is, however, no standard mechanism for this 322 signaling between MUAs and mailbox providers to trigger abuse 323 reports. 325 2. Feedback Providers SHOULD NOT send reports to recipients that are 326 uninvolved or only peripherally involved. For example, they 327 SHOULD NOT send reports to the operator of every Autonomous 328 System in the path between the apparent originating system and 329 the operator generating the report. Instead, they need to send 330 reports to recipients that are both responsible for the messages 331 and are able to do something about them. 332 3. Deciding where to send an unsolicited report will typically rely 333 on heuristics. Abuse addresses in WHOIS ([RFC3912]) records of 334 the IP address relaying the subject message and/or of the domain 335 name found in the results of a PTR ("reverse lookup") query on 336 that address are likely reasonable candidates, as is the 337 abuse@domain role address (see [RFC2142]) of related domains. 338 Unsolicited reports SHOULD NOT be sent to email addresses that 339 are not clearly intended to handle abuse reports. Legitimate 340 candidates include those found in WHOIS records or on a web site 341 that either are explicitly described as an abuse contact, or are 342 of the form "abuse@domain". 343 4. Where an abusive message is authenticated using a domain-level 344 authentication technology such as DKIM ([RFC6376]) or SPF 345 ([RFC4408]), the domain that has been verified by the 346 authentication mechanism is often a reasonable candidate for 347 receiving feedback about the message. For DKIM, though, while 348 the authenticated domain has some responsibility for the mail 349 sent, it can be a poor contact point for abuse issues (for 350 example, it could represent the message's author but not its 351 sender, it could identify the bad actor responsible for the 352 message, or it could refer to a domain that cannot receive mail 353 at all). 354 5. Often, unsolicited reports will have no meaning if sent to abuse 355 reporting addresses belonging to the abusive parties themselves. 356 In fact, it is possible that such reports might reveal 357 information about complainants. Reports SHOULD NOT be sent to 358 such addresses if they can be identified beforehand, except where 359 the abusive party is known to be responsive to such reports. 361 5.4. What To Put In Reports 363 1. Reports SHOULD use "Feedback-Type: abuse", but can use other 364 types as appropriate. However, the Mailbox Provider generating 365 the reports cannot assume that the operator receiving the reports 366 will treat different Feedback-Types differently. 367 2. Reports SHOULD include the following optional fields whenever 368 their corresponding values are available and applicable to the 369 report: Original-Mail-From, Arrival-Date, Source-IP, Original- 370 Rcpt-To. Other optional fields can be included, as the 371 implementer feels is appropriate. 373 3. Experience suggests use of ARF is advisable in most contexts. 374 Automated recipient systems can handle abuse reports sent in ARF 375 format at least as well as any other format such as plain text, 376 with or without a copy of the message attached. That holds even 377 for systems that did not request ARF format reports, assuming 378 such reports are generated considering the possibility of 379 recipients that don't use automated ARF parsing. Anyone sending 380 unsolicited reports in ARF format can legitimately presume that 381 some recipients will only be able to access the human readable 382 (first, text/plain) part of it, and SHOULD include all 383 information needed also in this part. Further, they SHOULD 384 ensure that the report is readable when viewed as plain text, to 385 give low-end ticketing systems as much assistance as possible. 386 In extreme cases, failure to take these steps may result in the 387 report being discarded or ignored. 389 5.5. What To Do With Reports 391 1. Receivers of unsolicited reports can take advantage of the 392 standardized parts of the ARF format to automate processing. 393 Independent of the sender of the report, they can improve 394 processing by separating valid from invalid reports by, for 395 example, looking for references to IP address ranges, domains, 396 and mailboxes for which the recipient organization is responsible 397 in the copy of the reported message, and by correlating multiple 398 reports of similar messages to identify bulk email senders. 399 2. Per Section 4.4 of [RFC6449], a network service provider MAY use 400 ARF data for automated forwarding of feedback messages to the 401 originating customer. 402 3. Published abuse mailbox addresses SHOULD NOT reject non-ARF 403 messages based solely on the format, as generation of ARF 404 messages can occasionally be unavailable or not applicable. 405 Deviation from this requirement could be done due to local policy 406 decisions regarding other message criteria. 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 Feedback Provider. 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 Feedback Provider sending unsolicited reports SHOULD NOT 416 generate reports for which a reply cannot 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 6. 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. Automatic feedback generators MUST select actual message 442 recipients based on data provided by willing report receivers. 443 In particular, recipients MUST NOT be selected using heuristics. 444 2. If the message under evaluation by the Verifier is an ARF 445 ([RFC5965]) message, a report MUST NOT be automatically 446 generated. 447 3. The message for a new report sent via SMTP MUST be constructed so 448 as to avoid amplification attacks, deliberate or otherwise. The 449 envelope sender address of the report MUST be chosen so that 450 these reports will not generate mail loops. Similar to Section 2 451 of [RFC3464], the envelope sender address of the report MUST be 452 chosen to ensure that no feedback reports will be issued in 453 response to the report itself. Therefore, when an SMTP 454 transaction is used to send a report, the MAIL FROM command 455 SHOULD use the NULL reverse-path, i.e., "MAIL FROM:<>". An 456 exception to this would be the use of a reverse-path selected 457 such that SPF checks on the report will pass; in such cases, the 458 operator will need to make provisions to avoid the amplification 459 attack or mail loop via other means. 460 4. Reports SHOULD use "Feedback-Type: auth-failure", but MAY use 461 other types as appropriate. However, the Mailbox Provider 462 generating the reports cannot assume that the operator receiving 463 the reports will treat different Feedback-Types differently. 464 5. These reports SHOULD include the following optional fields, 465 although they are optional in [RFC5965], whenever their 466 corresponding values are available: Original-Mail-From, Arrival- 467 Date, Source-IP, Original-Rcpt-To. Other optional fields can be 468 included, as the implementer feels is appropriate. 470 7. IANA Considerations 472 [RFC Editor: please remove this section prior to publication.] 474 This document has no IANA actions. 476 8. Security Considerations 478 8.1. In Other Documents 480 Implementers are strongly urged to review, at a minimum, the Security 481 Considerations sections of [RFC5965] and [RFC6449]. 483 8.2. Forgeries 485 Feedback Providers that relay user complaints directly, rather than 486 by reference to a stored message (e.g., IMAP or POP), could be duped 487 into sending a complaint about a message that the complaining user 488 never actually received, as an attack on the purported originator of 489 the falsified message. Feedback Providers need to be resilient to 490 such attack methods. 492 Also, these reports may be forged as easily as ordinary Internet 493 electronic mail. User agents and automatic mail handling facilities 494 (such as mail distribution list exploders) that wish to make 495 automatic use of reports of any kind should take appropriate 496 precautions to minimize the potential damage from denial-of-service 497 attacks. 499 Perhaps the simplest means of mitigating this threat is to assert 500 that these reports should themselves be signed with something like 501 DKIM and/or authorized by something like SPF. Note, however, that if 502 there is a problem with the email infrastructure at either end, DKIM 503 and/or SPF may result in reports that aren't trusted or even accepted 504 by their intended recipients, so it is important to make sure those 505 components are properly configured. Use of both technologies in 506 tandem can resolve this concern to a degree since they generally have 507 disjoint failure modes. 509 8.3. Amplification Attacks 511 Failure to comply with the recommendations regarding selection of the 512 envelope sender can lead to amplification denial-of-service attacks. 513 This is discussed in Section 6 as well as in [RFC3464]. 515 8.4. Automatic Generation 517 ARF ([RFC5965]) reports have historically been generated individually 518 as a result of some kind of human request, such as someone clicking a 519 "Report Abuse" button in a mail reader. In contrast, the mechanisms 520 described in some extension documents (i.e., 521 [I-D.IETF-MARF-DKIM-REPORTING] and [I-D.IETF-MARF-SPF-REPORTING]) are 522 focused around automated reporting. This obviously implies the 523 potential for much larger volumes or higher frequency of messages, 524 and thus greater mail system load (both for Feedback Providers and 525 report receivers). 527 Those mechanisms are primarily intended for use in generating reports 528 to aid implementers of DKIM ([RFC6376]), ADSP ([RFC5617]), and SPF 529 ([RFC4408]), and other related protocols during development and 530 debugging. They are not generally intended for prolonged forensic 531 use, specifically because of these load concerns. However, extended 532 use is possible by ADMDs that want to keep a close watch for fraud or 533 infrastructure problems. It is important to consider the impact of 534 doing so on both Feedback Providers and the requesting ADMDs. 536 A sender requesting these reports can cause its mail servers to be 537 overwhelmed if it sends out signed messages whose signatures fail to 538 verify for some reason, provoking a large number of reports from 539 Feedback Providers. Similarly, a Feedback Provider could be 540 overwhelmed by a large volume of messages requesting reports whose 541 signatures fail to validate, as those now need to send reports back 542 to the signer. 544 Limiting the rate of generation of these messages may be appropriate 545 but threatens to inhibit the distribution of important and possibly 546 time-sensitive information. 548 In general ARF feedback loop terms, it is often suggested that 549 Feedback Providers only create these (or any) ARF reports after an 550 out-of-band arrangement has been made between two parties. These 551 extension mechanisms then become ways to adjust parameters of an 552 authorized abuse report feedback loop that is configured and 553 activated by private agreement rather than starting to send them 554 automatically based solely on data found in the messages, which may 555 have unintended consequences. 557 8.5. Reporting Multiple Incidents 559 If it is known that a particular host generates abuse reports upon 560 certain incidents, an attacker could forge a high volume of messages 561 that will trigger such a report. The recipient of the report could 562 then be innundated with reports. This could easily be extended to a 563 distributed denial-of-service attack by finding a number of report- 564 generating servers. 566 The incident count referenced in ARF ([RFC5965]) provides a limited 567 form of mitigation. The host generating reports can elect to send 568 reports only periodically, with each report representing a number of 569 identical or nearly-identical incidents. One might even do something 570 inverse-exponentially, sending reports for each of the first ten 571 incidents, then every tenth incident up to 100, then every 100th 572 incident up to 1000, etc., until some period of relative quiet after 573 which the limitation resets. 575 The use of this for "nearly-identical" incidents in particular causes 576 a degradation in reporting quality, however. If for example a large 577 number of pieces of spam arrive from one attacker, a reporting agent 578 could decide only to send a report about a fraction of those 579 messages. While this averts a flood of reports to a system 580 administrator, the precise details of each incident are similarly not 581 sent. 583 Other rate limiting provisions might be considered, including 584 detection of a temporary failure response from the report destination 585 and thus halting report generation to that destination for some 586 period, or simply imposing or negotiating a hard limit on the number 587 of reports to be sent to a particular receiver in a given time frame. 589 9. Acknowledgements 591 The author and editor wish to thank Steve Atkins, John Levine, Shmuel 592 Metz, S. Moonesamy, and Alessandro Vesely for their contributions to 593 this memo. 595 All of the Best Practices referenced by this document are found in 596 [RFC6449], written within the Collaboration Committee of the 597 Messaging Anti-Abuse Working Group (MAAWG). 599 Finally, the original author wishes to thank the doctors and staff at 600 the University of Texas MD Anderson Cancer Center for doing what they 601 do. 603 10. References 605 10.1. Normative References 607 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 608 Requirement Levels", BCP 14, RFC 2119, March 1997. 610 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 611 October 2008. 613 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 614 October 2008. 616 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 617 July 2009. 619 [RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An 620 Extensible Format for Email Feedback Reports", RFC 5965, 621 August 2010. 623 10.2. Informative References 625 [I-D.IETF-MARF-DKIM-REPORTING] 626 Kucherawy, M., "Extensions to DKIM for Failure Reporting", 627 draft-ietf-marf-dkim-reporting (work in progress), 628 January 2012. 630 [I-D.IETF-MARF-SPF-REPORTING] 631 Kitterman, S., "SPF Authentication Failure Reporting using 632 the Abuse Report Format", draft-ietf-marf-spf-reporting 633 (work in progress), January 2012. 635 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 636 STD 53, RFC 1939, May 1996. 638 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 639 3", BCP 9, RFC 2026, October 1996. 641 [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 642 FUNCTIONS", RFC 2142, May 1997. 644 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 645 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 646 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 648 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 649 for Delivery Status Notifications", RFC 3464, 650 January 2003. 652 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 653 4rev1", RFC 3501, March 2003. 655 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 656 September 2004. 658 [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 659 for Authorizing Use of Domains in E-Mail, Version 1", 660 RFC 4408, April 2006. 662 [RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine, 663 "DomainKeys Identified Mail (DKIM) Author Domain Signing 664 Practices (ADSP)", RFC 5617, August 2009. 666 [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 667 Identified Mail (DKIM) Signatures", RFC 6376, 668 September 2011. 670 [RFC6430] Li, K. and B. Leiba, "Email Feedback Report Type Value: 671 not-spam", RFC 6430, November 2011. 673 [RFC6449] Falk, J., "Complaint Feedback Loop Operational 674 Recommendations", RFC 6449, November 2011. 676 [RFC6590] Falk, J. and M. Kucherawy, "Redaction of Potentially 677 Sensitive Data from Mail Abuse Reports", RFC 6590, 678 April 2012. 680 Authors' Addresses 682 J.D. Falk 683 Return Path 684 100 Mathilda Street, Suite 100 685 Sunnyvale, CA 94089 686 USA 688 URI: http://www.returnpath.net/ 690 M. Kucherawy (editor) 691 Cloudmark 692 128 King St., 2nd Floor 693 San Francisco, CA 94107 694 US 696 Email: msk@cloudmark.com