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