7Internet Engineering Task Force (IETF) J. Falk
8Request for Comments: 6650 Return Path
9Updates: 5965 M. Kucherawy, Ed.
10Category: Standards Track Cloudmark
11ISSN: 2070-1721 June 2012
14 Creation and Use of Email Feedback Reports:
15 An Applicability Statement for the Abuse Reporting Format (ARF)
19 RFC 5965 defines an extensible, machine-readable format intended for
20 mail operators to report feedback about received email to other
21 parties. This applicability statement describes common methods for
22 utilizing this format for reporting both abuse and authentication
23 failure events. Mailbox Providers of any size, mail-sending
24 entities, and end users can use these methods as a basis to create
25 procedures that best suit them. Some related optional mechanisms are
30 This is an Internet Standards Track document.
32 This document is a product of the Internet Engineering Task Force
33 (IETF). It represents the consensus of the IETF community. It has
34 received public review and has been approved for publication by the
35 Internet Engineering Steering Group (IESG). Further information on
36 Internet Standards is available in Section 2 of RFC 5741.
38 Information about the current status of this document, any errata,
39 and how to provide feedback on it may be obtained at
40 http://www.rfc-editor.org/info/rfc6650.
58Falk & Kucherawy Standards Track [Page 1]
60RFC 6650 ARF AS June 2012
65 Copyright (c) 2012 IETF Trust and the persons identified as the
66 document authors. All rights reserved.
68 This document is subject to BCP 78 and the IETF Trust's Legal
69 Provisions Relating to IETF Documents
70 (http://trustee.ietf.org/license-info) in effect on the date of
71 publication of this document. Please review these documents
72 carefully, as they describe your rights and restrictions with respect
73 to this document. Code Components extracted from this document must
74 include Simplified BSD License text as described in Section 4.e of
75 the Trust Legal Provisions and are provided without warranty as
76 described in the Simplified BSD License.
80 1. Introduction ....................................................3
81 2. Definitions .....................................................4
82 3. Solicited and Unsolicited Reports ...............................4
83 4. Generating and Handling Solicited Abuse Reports .................4
84 4.1. General Considerations for Feedback Providers ..............4
85 4.2. Where to Send Reports ......................................5
86 4.3. What to Put in Reports .....................................5
87 4.4. General Considerations for Feedback Consumers ..............5
88 4.5. What to Expect .............................................6
89 4.6. What to Do with Reports ....................................6
90 5. Generating and Handling Unsolicited Abuse Reports ...............6
91 5.1. General Considerations .....................................6
92 5.2. When to Generate Reports ...................................7
93 5.3. Where to Send Reports ......................................7
94 5.4. What to Put in Reports .....................................8
95 5.5. What to Do with Reports ....................................9
96 6. Generating Automatic Authentication Failure Reports ............10
97 7. Security Considerations ........................................11
98 7.1. Security Considerations in Other Documents ................11
99 7.2. Forgeries .................................................11
100 7.3. Amplification Attacks .....................................11
101 7.4. Automatic Generation ......................................11
102 7.5. Reporting Multiple Incidents ..............................12
103 8. Acknowledgements ...............................................13
104 9. References .....................................................13
105 9.1. Normative References ......................................13
106 9.2. Informative References ....................................14
114Falk & Kucherawy Standards Track [Page 2]
116RFC 6650 ARF AS June 2012
121 The Abuse Reporting Format (ARF) was initially developed for two very
122 specific use cases. Initially, it was intended to be used for
123 reporting feedback between large email operators, or from large email
124 operators to end user network access operators, any of whom could be
125 presumed to have automated abuse-handling systems. Secondarily, it
126 is used by those same large mail operators to send those same reports
127 to other entities, including those involved in sending bulk email for
128 commercial purposes. In either case, the reports would be triggered
129 by direct end user action such as clicking on a "report spam" button
130 in their email client.
132 Though other uses for ARF as defined in [RFC5965] have been discussed
133 (and may be documented similarly in the future), abuse reporting
134 remains the primary application, with a small amount of adoption of
135 extensions that enable authentication failure reporting.
137 This applicability statement provides direction for using ARF in both
138 contexts. It also includes some statements about the use of ARF in
139 conjunction with other email technologies.
141 The purpose for reporting abusive messages is to stop recurrences.
142 The methods described in this document focus on automating abuse
143 reporting as much as practical, so as to minimize the work of a
144 site's abuse team. There are further reasons why abuse feedback
145 generation is worthwhile, such as instruction of mail filters or
146 reputation trackers, or initiation of investigations of particularly
147 egregious abuses. These other applications are not discussed in
150 Further introduction to this topic may be found in [RFC6449], which
151 has more information about the general topic of abuse reporting.
152 Many of the specific ARF guidelines in this document were taken from
153 the principles presented in [RFC6449].
155 At the time of publication of this document, five feedback types are
156 registered. This document only discusses two of them ("abuse"
157 [RFC5965] and "auth-failure" [RFC6591]), as they are seeing
158 sufficient use in practice that applicability statements can be made
159 about them. The others, i.e., "fraud" [RFC5965], "other" [RFC5965],
160 and "not-spam" [RFC6430], are either too new or too seldom used to be
170Falk & Kucherawy Standards Track [Page 3]
172RFC 6650 ARF AS June 2012
177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
179 document are to be interpreted as described in [RFC2119] and are
180 intended to replace the Requirement Levels described in Section 3.3
183 Some of the terminology used in this document is taken from
186 "Mailbox Provider" refers to an organization that accepts, stores,
187 and offers access to [RFC5322] messages ("email messages") for end
188 users. Such an organization has typically implemented SMTP [RFC5321]
189 and might provide access to messages through IMAP [RFC3501], the Post
190 Office Protocol (POP) [RFC1939], a proprietary interface designed for
191 HTTP [RFC2616], or a proprietary protocol.
1933. Solicited and Unsolicited Reports
195 The original, and still by far the most common, application of
196 [RFC5965] is when two mail systems make a private agreement to
197 exchange abuse reports -- usually reports due to recipients manually
198 reporting messages as spam. We refer to these as solicited reports.
200 Other uses for ARF involve such reports sent between parties that
201 don't know each other. These unsolicited reports are sent without
202 prior arrangement between the parties as to the context and meaning
203 of the reports. Therefore, the constraints on how these unsolicited
204 reports need to be structured such that they are likely to be useful
205 to the recipient -- e.g., to what address(es) they can usefully be
206 sent, what issues they can be used to report, and how they can be
207 handled by the receiver of the report -- are very different.
209 The two cases are covered separately in the sections that follow.
2114. Generating and Handling Solicited Abuse Reports
2134.1. General Considerations for Feedback Providers
215 A Mailbox Provider receives reports of abusive or unwanted mail from
216 its users, most often by providing a "report spam" button (or similar
217 nomenclature) in the MUA (Mail User Agent). The method of
218 transferring this message and any associated metadata from the MUA to
219 the Mailbox Provider's ARF processing system is not defined by any
220 standards document but is discussed further in Section 3.2 of
221 [RFC6449]. Policy concerns related to the collection of this data
222 are discussed in Section 3.4 of [RFC6449].
226Falk & Kucherawy Standards Track [Page 4]
228RFC 6650 ARF AS June 2012
231 To implement the recommendations of this memo, the reports are
232 formatted per [RFC5965] and transmitted as an email message
233 [RFC5322], typically using SMTP [RFC5321].
235 Ongoing maintenance of an ARF processing system is discussed in
236 Section 3.6 of [RFC6449].
2384.2. Where to Send Reports
240 The Mailbox Provider SHOULD NOT send reports to addresses that have
241 not explicitly requested them. A valid deviation might be the result
242 of local policy instructions. The process whereby such parties may
243 request the reports is discussed in Section 3.5 of [RFC6449].
2454.3. What to Put in Reports
247 The reports SHOULD use "Feedback-Type: abuse" for the report type.
248 Although a Mailbox Provider generating the reports can use other
249 types appropriate to the nature of the abuse being reported, the
250 operator receiving the reports might not treat different feedback
253 The following fields are optional in [RFC5965] but SHOULD be used in
254 this context when their corresponding values are available:
255 Original-Mail-From, Arrival-Date, Source-IP, and Original-Rcpt-To.
256 Other optional fields can be included as deemed appropriate by the
259 User-identifiable data MAY be obscured as described in [RFC6590].
2614.4. General Considerations for Feedback Consumers
263 ARF report streams are established proactively between Feedback
264 Providers and Feedback Consumers. Recommendations for preparing to
265 request feedback are discussed in Section 4.1 of [RFC6449].
267 Operators MUST be able to accept ARF [RFC5965] reports as email
268 messages [RFC5322] over SMTP [RFC5321]. These messages, and other
269 types of email messages that can be received, are discussed in
270 Section 4.2 of [RFC6449].
272 Recipients of feedback reports that are part of formal feedback
273 arrangements have to be capable of handling large volumes of reports.
274 This could require automation of report processing as discussed in
275 Section 4.4 of [RFC6449].
282Falk & Kucherawy Standards Track [Page 5]
284RFC 6650 ARF AS June 2012
289 The list of valid Feedback-Types is defined in [RFC5965], which
290 created an IANA registry for valid values to allow for extensions.
291 However, to allow for handling of new types that are not yet
292 supported, an automated report processing system MUST NOT reject (in
293 the SMTP sense) a report based solely on an unknown Feedback-Type.
294 The automated system can simply set reports of unknown types aside
295 for manual handling. However, Mailbox Providers might only make use
296 of the "abuse" Feedback-Type. Therefore, report receivers might be
297 required to do additional analysis to separate different types of
298 abuse reports after receipt if they do not have prior specific
299 knowledge of the sender of the report.
301 Report receivers MUST accept reports that have obscured their user-
302 identifiable data as described in [RFC6590]. That document also
303 discusses the handling of such reports. This technique is also
304 discussed in Section 4.4 of [RFC6449].
3064.6. What to Do with Reports
308 Section 4.3 of [RFC6449] discusses actions that mail operators might
309 take upon receiving a report (or multiple reports).
3115. Generating and Handling Unsolicited Abuse Reports
3135.1. General Considerations
315 It is essential for report recipients to be capable of throttling
316 reports being sent to avoid damage to their own installations.
317 Therefore, Feedback Providers MUST provide a way for report
318 recipients to request that no further reports be sent.
319 Unfortunately, no standardized mechanism for such requests exists to
320 date, and all existing mechanisms for meeting this requirement are
323 Message authentication is generally a good idea, but it is especially
324 important to encourage credibility of, and thus response to,
325 unsolicited reports. Therefore, as with any other message, Feedback
326 Providers sending unsolicited reports SHOULD send reports that they
327 expect will pass the Sender Policy Framework (SPF) [RFC4408] and/or
328 DomainKeys Identified Mail (DKIM) [RFC6376] checks.
338Falk & Kucherawy Standards Track [Page 6]
340RFC 6650 ARF AS June 2012
3435.2. When to Generate Reports
345 Handling of unsolicited reports has a significant cost to the report
346 receiver. Senders of unsolicited reports, especially those sending
347 large volumes of them automatically, SHOULD NOT send reports that
348 cannot be used as a basis for action by the recipient, whether this
349 is due to the report being sent about an incident that is not abuse-
350 related, the report being sent to an email address that won't result
351 in action, or the content or format of the report being hard for the
352 recipient to read or use.
354 Feedback Providers SHOULD NOT report all mail sent from a particular
355 sender merely because some of it is determined to be abusive.
357 Mechanical reports of mail that "looks like" spam, based solely on
358 the results of inline content analysis tools, SHOULD NOT be sent
359 since, because of their subjective nature, they are unlikely to
360 provide a basis for the recipient to take action. Complaints
361 generated by end users about mail that is determined by them to be
362 abusive, or mail delivered to "spam trap" or "honeypot" addresses,
363 are far more likely to be accurate and MAY be sent.
365 If a Feedback Provider applies SPF [RFC4408] to arriving messages, a
366 report SHOULD NOT be generated to the RFC5321.MailFrom domain if the
367 SPF evaluation produced a "Fail", "SoftFail", "TempError", or
368 "PermError" report, as no reliable assertion or assumption can be
369 made that use of the domain was authorized. A valid exception would
370 be specific knowledge that the SPF result is not definitive for that
371 domain under those circumstances (for example, a message that is also
372 signed using DKIM [RFC6376] by the same domain, and that signature
3755.3. Where to Send Reports
377 Rather than generating feedback reports themselves, MUAs SHOULD
378 create abuse reports and send these reports back to their Mailbox
379 Providers so that they can generate and send ARF messages on behalf
380 of end users (see Section 3.2 of [RFC6449]). This allows centralized
381 processing and tracking of reports, and provides training input to
382 filtering systems. There is, however, no standard mechanism for this
383 signaling between MUAs and Mailbox Providers to trigger abuse
386 Feedback Providers SHOULD NOT send reports to recipients that are
387 uninvolved or only peripherally involved. For example, they SHOULD
388 NOT send reports to the operator of every Autonomous System in the
389 path between the apparent originating system and the operator
394Falk & Kucherawy Standards Track [Page 7]
396RFC 6650 ARF AS June 2012
399 generating the report. Instead, they need to send reports to
400 recipients that are both responsible for the messages and able to do
401 something about them.
403 Deciding where to send an unsolicited report will typically rely on
404 heuristics. Abuse addresses in WHOIS [RFC3912] records of the IP
405 address relaying the subject message and/or of the domain name found
406 in the results of a PTR ("reverse lookup") query on that address are
407 likely reasonable candidates, as is the abuse@domain role address
408 (see [RFC2142]) of related domains. Unsolicited reports SHOULD NOT
409 be sent to email addresses that are not clearly intended to handle
410 abuse reports. Legitimate candidates include those found in WHOIS
411 records or on a web site that either are explicitly described as an
412 abuse contact or are of the form "abuse@domain".
414 Where an abusive message is authenticated using a domain-level
415 authentication technology such as DKIM [RFC6376] or SPF [RFC4408],
416 the domain that has been verified by the authentication mechanism is
417 often a reasonable candidate for receiving feedback about the
418 message. For DKIM, though, while the authenticated domain has some
419 responsibility for the mail sent, it can be a poor contact point for
420 abuse issues (for example, it could represent the message's author
421 but not its sender, it could identify the bad actor responsible for
422 the message, or it could refer to a domain that cannot receive mail
425 Often, unsolicited reports will have no meaning if sent to abuse
426 reporting addresses belonging to the abusive parties themselves. In
427 fact, it is possible that such reports might reveal information about
428 complainants. Reports SHOULD NOT be sent to such addresses if they
429 can be identified beforehand, except where the abusive party is known
430 to be responsive to such reports.
4325.4. What to Put in Reports
434 Reports SHOULD use "Feedback-Type: abuse" but can use other types as
435 appropriate. However, the Mailbox Provider generating the reports
436 cannot assume that the operator receiving the reports will treat
437 different Feedback-Types differently.
439 Reports SHOULD include the following optional fields whenever their
440 corresponding values are available and applicable to the report:
441 Original-Mail-From, Arrival-Date, Source-IP, and Original-Rcpt-To.
442 Other optional fields can be included as deemed appropriate by the
450Falk & Kucherawy Standards Track [Page 8]
452RFC 6650 ARF AS June 2012
455 Experience suggests that the use of ARF is advisable in most
456 contexts. Automated recipient systems can handle abuse reports sent
457 in ARF at least as well as any other format such as plain text, with
458 or without a copy of the message attached. That holds even for
459 systems that did not request ARF reports, assuming such reports are
460 generated considering the possibility of recipients that don't use
461 automated ARF parsing. Anyone sending unsolicited reports in ARF can
462 legitimately presume that some recipients will only be able to access
463 the human-readable (first, text/plain) part of it and SHOULD include
464 all information needed also in this part. Further, they SHOULD
465 ensure that the report is readable when viewed as plain text, to give
466 low-end ticketing systems as much assistance as possible. In extreme
467 cases, failure to take these steps may result in the report being
468 discarded or ignored.
4705.5. What to Do with Reports
472 Receivers of unsolicited reports can take advantage of the
473 standardized parts of ARF to automate processing. Independent of the
474 sender of the report, they can improve processing by separating valid
475 reports from invalid reports by, for example, looking for references
476 to IP address ranges, domains, and mailboxes for which the recipient
477 organization is responsible in the copy of the reported message, and
478 by correlating multiple reports of similar messages to identify bulk
481 Per Section 4.4 of [RFC6449], a network service provider MAY use ARF
482 data for automated forwarding of feedback messages to the originating
485 Published abuse mailbox addresses SHOULD NOT reject non-ARF messages
486 based solely on the format, as generation of ARF messages can
487 occasionally be unavailable or not applicable. Deviation from this
488 requirement could be done due to local policy decisions regarding
489 other message criteria.
491 Although [RFC6449] suggests that replying to feedback is not useful,
492 in the case of receipt of ARF reports where no feedback arrangement
493 has been established, a non-automated reply might be desirable to
494 indicate what action resulted from the complaint, heading off more
495 severe filtering by the Feedback Provider. In addition, using an
496 address that cannot receive replies precludes any requests for
497 additional information and increases the likelihood that further
498 reports will be discarded or blocked. Thus, a Feedback Provider
499 sending unsolicited reports SHOULD NOT generate reports for which a
500 reply cannot be received. Where an unsolicited report results in the
501 establishment of contact with a responsible and responsive party,
502 this data can be saved for future complaint handling and possible
506Falk & Kucherawy Standards Track [Page 9]
508RFC 6650 ARF AS June 2012
511 establishment of a formal (solicited) feedback arrangement. See
512 Section 3.5 of [RFC6449] for a discussion of establishment of
513 feedback arrangements.
5156. Generating Automatic Authentication Failure Reports
517 There are some cases where report generation is caused by automation
518 rather than user requests. A specific example of this is reporting,
519 using ARF (or extensions to it), of messages that fail particular
520 message authentication checks. Examples of this include [RFC6651]
521 and [RFC6652]. The considerations presented below apply in those
524 The applicability statement for this use case is somewhat smaller, as
525 many of the issues associated with abuse reports are not relevant to
526 reports about authentication failures.
528 Automatic feedback generators MUST select actual message recipients
529 based on data provided by willing report receivers. In particular,
530 recipients MUST NOT be selected using heuristics.
532 If the message under evaluation by the Verifier is an ARF [RFC5965]
533 message, a report MUST NOT be automatically generated.
535 The message for a new report sent via SMTP MUST be constructed so as
536 to avoid amplification attacks, deliberate or otherwise. The
537 envelope sender address of the report MUST be chosen so that these
538 reports will not generate mail loops. Similar to Section 2 of
539 [RFC3464], the envelope sender address of the report MUST be chosen
540 to ensure that no feedback reports will be issued in response to the
541 report itself. Therefore, when an SMTP transaction is used to send a
542 report, the MAIL FROM command SHOULD use the NULL reverse-path, i.e.,
543 "MAIL FROM:<>". An exception to this would be the use of a reverse-
544 path selected such that SPF checks on the report will pass; in such
545 cases, the operator will need to make provisions to avoid the
546 amplification attack or mail loop via other means.
548 Reports SHOULD use "Feedback-Type: auth-failure" but MAY use other
549 types as appropriate. However, the Mailbox Provider generating the
550 reports cannot assume that the operator receiving the reports will
551 treat different Feedback-Types differently.
553 These reports SHOULD include the following fields, although they are
554 optional in [RFC5965], whenever their corresponding values are
555 available: Original-Mail-From, Arrival-Date, Source-IP, and
556 Original-Rcpt-To. Other optional fields can be included as deemed
557 appropriate by the implementer.
562Falk & Kucherawy Standards Track [Page 10]
564RFC 6650 ARF AS June 2012
5677. Security Considerations
5697.1. Security Considerations in Other Documents
571 Implementers are strongly urged to review, at a minimum, the Security
572 Considerations sections of [RFC5965] and [RFC6449].
576 Feedback Providers that relay user complaints directly, rather than
577 by reference to a stored message (e.g., IMAP or POP), could be duped
578 into sending a complaint about a message that the complaining user
579 never actually received, as an attack on the purported originator of
580 the falsified message. Feedback Providers need to be resilient to
583 Also, these reports may be forged as easily as ordinary Internet
584 electronic mail. User agents and automatic mail handling facilities
585 (such as mail distribution list exploders) that wish to make
586 automatic use of reports of any kind should take appropriate
587 precautions to minimize the potential damage from denial-of-service
590 Perhaps the simplest means of mitigating this threat is to assert
591 that these reports should themselves be signed with something like
592 DKIM and/or authorized by something like SPF. Note, however, that if
593 there is a problem with the email infrastructure at either end, DKIM
594 and/or SPF may result in reports that aren't trusted or even accepted
595 by their intended recipients, so it is important to make sure those
596 components are properly configured. The use of both technologies in
597 tandem can resolve this concern to a degree, since they generally
598 have disjoint failure modes.
6007.3. Amplification Attacks
602 Failure to comply with the recommendations regarding selection of the
603 envelope sender can lead to amplification denial-of-service attacks.
604 This is discussed in Section 6 as well as in [RFC3464].
6067.4. Automatic Generation
608 ARF [RFC5965] reports have historically been generated individually
609 as a result of some kind of human request, such as someone clicking a
610 "Report Abuse" button in a mail reader. In contrast, the mechanisms
611 described in some extension documents (i.e., [RFC6651] and [RFC6652])
612 are focused around automated reporting. This obviously implies the
618Falk & Kucherawy Standards Track [Page 11]
620RFC 6650 ARF AS June 2012
623 potential for much larger volumes or higher frequency of messages,
624 and thus greater mail system load (both for Feedback Providers and
627 Those mechanisms are primarily intended for use in generating reports
628 to aid implementers of DKIM [RFC6376], Author Domain Signing
629 Practices (ADSP) [RFC5617], and SPF [RFC4408], and other related
630 protocols during development and debugging. They are not generally
631 intended for prolonged forensic use, specifically because of these
632 load concerns. However, extended use is possible by ADministrative
633 Management Domains (ADMDs) that want to keep a close watch for fraud
634 or infrastructure problems. It is important to consider the impact
635 of doing so on both Feedback Providers and the requesting ADMDs.
637 A sender requesting these reports can cause its mail servers to be
638 overwhelmed if it sends out signed messages whose signatures fail to
639 verify for some reason, provoking a large number of reports from
640 Feedback Providers. Similarly, a Feedback Provider could be
641 overwhelmed by a large volume of messages requesting reports whose
642 signatures fail to validate, as the Feedback Provider now needs to
643 send reports back to the Signer.
645 Limiting the rate of generation of these messages may be appropriate
646 but threatens to inhibit the distribution of important and possibly
647 time-sensitive information.
649 In general ARF feedback loop terms, it is often suggested that
650 Feedback Providers only create these (or any) ARF reports after an
651 out-of-band arrangement has been made between two parties. These
652 extension mechanisms provide ways to adjust parameters of an
653 authorized abuse report feedback loop that is configured and
654 activated by private agreement. The alternative (sending reports
655 automatically based solely on data found in the messages) may have
656 unintended consequences.
6587.5. Reporting Multiple Incidents
660 If it is known that a particular host generates abuse reports upon
661 certain incidents, an attacker could forge a high volume of messages
662 that will trigger such a report. The recipient of the report could
663 then be inundated with reports. This could easily be extended to a
664 distributed denial-of-service attack by finding a number of report-
667 The incident count referenced in ARF [RFC5965] provides a limited
668 form of mitigation. The host that generates reports can elect to
669 send reports only periodically, with each report representing a
670 number of identical or nearly identical incidents. One might even do
674Falk & Kucherawy Standards Track [Page 12]
676RFC 6650 ARF AS June 2012
679 something inverse-exponentially, sending reports for each of the
680 first ten incidents, then every tenth incident up to 100, then every
681 100th incident up to 1000, etc., until some period of relative quiet
682 after which the limitation resets.
684 The use of this technique for "nearly identical" incidents in
685 particular causes a degradation in reporting quality, however. If
686 for example a large number of pieces of spam arrive from one
687 attacker, a reporting agent could decide only to send a report about
688 a fraction of those messages. While this averts a flood of reports
689 to a system administrator, the precise details of each incident are
692 Other rate-limiting provisions might be considered, such as detecting
693 a temporary failure response from the report destination and thus
694 halting report generation to that destination for some period, or
695 simply imposing or negotiating a hard limit on the number of reports
696 to be sent to a particular receiver in a given time frame.
700 The author and editor wish to thank Steve Atkins, John Levine, Shmuel
701 Metz, S. Moonesamy, and Alessandro Vesely for their contributions to
704 All of the best practices referenced by this document are found in
705 [RFC6449], written within the Collaboration Committee of the
706 Messaging Anti-Abuse Working Group (MAAWG).
708 Finally, the original author wishes to thank the doctors and staff
709 at the University of Texas MD Anderson Cancer Center for doing what
7149.1. Normative References
716 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
717 Requirement Levels", BCP 14, RFC 2119, March 1997.
719 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
722 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
725 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
730Falk & Kucherawy Standards Track [Page 13]
732RFC 6650 ARF AS June 2012
735 [RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An
736 Extensible Format for Email Feedback Reports", RFC 5965,
739 [RFC6591] Fontana, H., "Authentication Failure Reporting Using the
740 Abuse Reporting Format", RFC 6591, April 2012.
7429.2. Informative References
744 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
745 STD 53, RFC 1939, May 1996.
747 [RFC2026] Bradner, S., "The Internet Standards Process --
748 Revision 3", BCP 9, RFC 2026, October 1996.
750 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and
751 Functions", RFC 2142, May 1997.
753 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
754 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
755 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
757 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format
758 for Delivery Status Notifications", RFC 3464,
761 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
762 VERSION 4rev1", RFC 3501, March 2003.
764 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
767 [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
768 for Authorizing Use of Domains in E-Mail, Version 1",
769 RFC 4408, April 2006.
771 [RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine,
772 "DomainKeys Identified Mail (DKIM) Author Domain Signing
773 Practices (ADSP)", RFC 5617, August 2009.
775 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
776 "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376,
779 [RFC6430] Li, K. and B. Leiba, "Email Feedback Report Type Value:
780 not-spam", RFC 6430, November 2011.
786Falk & Kucherawy Standards Track [Page 14]
788RFC 6650 ARF AS June 2012
791 [RFC6449] Falk, J., Ed., "Complaint Feedback Loop Operational
792 Recommendations", RFC 6449, November 2011.
794 [RFC6590] Falk, J., Ed., and M. Kucherawy, Ed., "Redaction of
795 Potentially Sensitive Data from Mail Abuse Reports",
796 RFC 6590, April 2012.
798 [RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail
799 (DKIM) for Failure Reporting", RFC 6651, June 2012.
801 [RFC6652] Kitterman, S., "Sender Policy Framework (SPF)
802 Authentication Failure Reporting Using the Abuse Reporting
803 Format", RFC 6652, June 2012.
809 100 Mathilda Place, Suite 100
813 URI: http://www.returnpath.net/
816 Murray S. Kucherawy (editor)
818 128 King St., 2nd Floor
819 San Francisco, CA 94107
822 EMail: superuser@gmail.com
842Falk & Kucherawy Standards Track [Page 15]