    Internet Engineering Task Force (IETF)                           J. Falk
    Request for Comments: 6650                                   Return Path
    Updates: 5965                                          M. Kucherawy, Ed.
    Category: Standards Track                                      Cloudmark
    ISSN: 2070-1721                                                June 2012

                  Creation and Use of Email Feedback Reports:
        An Applicability Statement for the Abuse Reporting Format (ARF)

    Abstract

       RFC 5965 defines an extensible, machine-readable format intended for
       mail operators to report feedback about received email to other
       parties.  This applicability statement describes common methods for
       utilizing this format for reporting both abuse and authentication
       failure events.  Mailbox Providers of any size, mail-sending
       entities, and end users can use these methods as a basis to create
       procedures that best suit them.  Some related optional mechanisms are
       also discussed.

    Status of This Memo

       This is an Internet Standards Track document.

       This document is a product of the Internet Engineering Task Force
       (IETF).  It represents the consensus of the IETF community.  It has
       received public review and has been approved for publication by the
       Internet Engineering Steering Group (IESG).  Further information on
       Internet Standards is available in Section 2 of RFC 5741.

       Information about the current status of this document, any errata,
       and how to provide feedback on it may be obtained at
       http://www.rfc-editor.org/info/rfc6650.

    Falk & Kucherawy             Standards Track                    [Page 1]

    RFC 6650                         ARF AS                        June 2012

    Copyright Notice

       Copyright (c) 2012 IETF Trust and the persons identified as the
       document authors.  All rights reserved.

       This document is subject to BCP 78 and the IETF Trust's Legal
       Provisions Relating to IETF Documents
       (http://trustee.ietf.org/license-info) in effect on the date of
       publication of this document.  Please review these documents
       carefully, as they describe your rights and restrictions with respect
       to this document.  Code Components extracted from this document must
       include Simplified BSD License text as described in Section 4.e of
       the Trust Legal Provisions and are provided without warranty as
       described in the Simplified BSD License.

    Table of Contents

       1. Introduction ....................................................3
       2. Definitions .....................................................4
       3. Solicited and Unsolicited Reports ...............................4
       4. Generating and Handling Solicited Abuse Reports .................4
          4.1. General Considerations for Feedback Providers ..............4
          4.2. Where to Send Reports ......................................5
          4.3. What to Put in Reports .....................................5
          4.4. General Considerations for Feedback Consumers ..............5
          4.5. What to Expect .............................................6
          4.6. What to Do with Reports ....................................6
       5. Generating and Handling Unsolicited Abuse Reports ...............6
          5.1. General Considerations .....................................6
          5.2. When to Generate Reports ...................................7
          5.3. Where to Send Reports ......................................7
          5.4. What to Put in Reports .....................................8
          5.5. What to Do with Reports ....................................9
       6. Generating Automatic Authentication Failure Reports ............10
       7. Security Considerations ........................................11
          7.1. Security Considerations in Other Documents ................11
          7.2. Forgeries .................................................11
          7.3. Amplification Attacks .....................................11
          7.4. Automatic Generation ......................................11
          7.5. Reporting Multiple Incidents ..............................12
       8. Acknowledgements ...............................................13
       9. References .....................................................13
          9.1. Normative References ......................................13
          9.2. Informative References ....................................14

    Falk & Kucherawy             Standards Track                    [Page 2]

    RFC 6650                         ARF AS                        June 2012

    1.  Introduction

       The Abuse Reporting Format (ARF) was initially developed for two very
       specific use cases.  Initially, it was intended to be used for
       reporting feedback between large email operators, or from large email
       operators to end user network access operators, any of whom could be
       presumed to have automated abuse-handling systems.  Secondarily, it
       is used by those same large mail operators to send those same reports
       to other entities, including those involved in sending bulk email for
       commercial purposes.  In either case, the reports would be triggered
       by direct end user action such as clicking on a "report spam" button
       in their email client.

       Though other uses for ARF as defined in [RFC5965] have been discussed
       (and may be documented similarly in the future), abuse reporting
       remains the primary application, with a small amount of adoption of
       extensions that enable authentication failure reporting.

       This applicability statement provides direction for using ARF in both
       contexts.  It also includes some statements about the use of ARF in
       conjunction with other email technologies.

       The purpose for reporting abusive messages is to stop recurrences.
       The methods described in this document focus on automating abuse
       reporting as much as practical, so as to minimize the work of a
       site's abuse team.  There are further reasons why abuse feedback
       generation is worthwhile, such as instruction of mail filters or
       reputation trackers, or initiation of investigations of particularly
       egregious abuses.  These other applications are not discussed in
       this memo.

       Further introduction to this topic may be found in [RFC6449], which
       has more information about the general topic of abuse reporting.
       Many of the specific ARF guidelines in this document were taken from
       the principles presented in [RFC6449].

       At the time of publication of this document, five feedback types are
       registered.  This document only discusses two of them ("abuse"
       [RFC5965] and "auth-failure" [RFC6591]), as they are seeing
       sufficient use in practice that applicability statements can be made
       about them.  The others, i.e., "fraud" [RFC5965], "other" [RFC5965],
       and "not-spam" [RFC6430], are either too new or too seldom used to be
       included here.

    Falk & Kucherawy             Standards Track                    [Page 3]

    RFC 6650                         ARF AS                        June 2012

    2.  Definitions

       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
       "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
       document are to be interpreted as described in [RFC2119] and are
       intended to replace the Requirement Levels described in Section 3.3
       of [RFC2026].

       Some of the terminology used in this document is taken from
       [RFC5598].

       "Mailbox Provider" refers to an organization that accepts, stores,
       and offers access to [RFC5322] messages ("email messages") for end
       users.  Such an organization has typically implemented SMTP [RFC5321]
       and might provide access to messages through IMAP [RFC3501], the Post
       Office Protocol (POP) [RFC1939], a proprietary interface designed for
       HTTP [RFC2616], or a proprietary protocol.

    3.  Solicited and Unsolicited Reports

       The original, and still by far the most common, application of
       [RFC5965] is when two mail systems make a private agreement to
       exchange abuse reports -- usually reports due to recipients manually
       reporting messages as spam.  We refer to these as solicited reports.

       Other uses for ARF involve such reports sent between parties that
       don't know each other.  These unsolicited reports are sent without
       prior arrangement between the parties as to the context and meaning
       of the reports.  Therefore, the constraints on how these unsolicited
       reports need to be structured such that they are likely to be useful
       to the recipient -- e.g., to what address(es) they can usefully be
       sent, what issues they can be used to report, and how they can be
       handled by the receiver of the report -- are very different.

       The two cases are covered separately in the sections that follow.

    4.  Generating and Handling Solicited Abuse Reports

    4.1.  General Considerations for Feedback Providers

       A Mailbox Provider receives reports of abusive or unwanted mail from
       its users, most often by providing a "report spam" button (or similar
       nomenclature) in the MUA (Mail User Agent).  The method of
       transferring this message and any associated metadata from the MUA to
       the Mailbox Provider's ARF processing system is not defined by any
       standards document but is discussed further in Section 3.2 of
       [RFC6449].  Policy concerns related to the collection of this data
       are discussed in Section 3.4 of [RFC6449].

    Falk & Kucherawy             Standards Track                    [Page 4]

    RFC 6650                         ARF AS                        June 2012

       To implement the recommendations of this memo, the reports are
       formatted per [RFC5965] and transmitted as an email message
       [RFC5322], typically using SMTP [RFC5321].

       Ongoing maintenance of an ARF processing system is discussed in
       Section 3.6 of [RFC6449].

    4.2.  Where to Send Reports

       The Mailbox Provider SHOULD NOT send reports to addresses that have
       not explicitly requested them.  A valid deviation might be the result
       of local policy instructions.  The process whereby such parties may
       request the reports is discussed in Section 3.5 of [RFC6449].

    4.3.  What to Put in Reports

       The reports SHOULD use "Feedback-Type: abuse" for the report type.
       Although a Mailbox Provider generating the reports can use other
       types appropriate to the nature of the abuse being reported, the
       operator receiving the reports might not treat different feedback
       types differently.

       The following fields are optional in [RFC5965] but SHOULD be used in
       this context when their corresponding values are available:
       Original-Mail-From, Arrival-Date, Source-IP, and Original-Rcpt-To.
       Other optional fields can be included as deemed appropriate by the
       implementer.

       User-identifiable data MAY be obscured as described in [RFC6590].

    4.4.  General Considerations for Feedback Consumers

       ARF report streams are established proactively between Feedback
       Providers and Feedback Consumers.  Recommendations for preparing to
       request feedback are discussed in Section 4.1 of [RFC6449].

       Operators MUST be able to accept ARF [RFC5965] reports as email
       messages [RFC5322] over SMTP [RFC5321].  These messages, and other
       types of email messages that can be received, are discussed in
       Section 4.2 of [RFC6449].

       Recipients of feedback reports that are part of formal feedback
       arrangements have to be capable of handling large volumes of reports.
       This could require automation of report processing as discussed in
       Section 4.4 of [RFC6449].

    Falk & Kucherawy             Standards Track                    [Page 5]

    RFC 6650                         ARF AS                        June 2012

    4.5.  What to Expect

       The list of valid Feedback-Types is defined in [RFC5965], which
       created an IANA registry for valid values to allow for extensions.
       However, to allow for handling of new types that are not yet
       supported, an automated report processing system MUST NOT reject (in
       the SMTP sense) a report based solely on an unknown Feedback-Type.
       The automated system can simply set reports of unknown types aside
       for manual handling.  However, Mailbox Providers might only make use
       of the "abuse" Feedback-Type.  Therefore, report receivers might be
       required to do additional analysis to separate different types of
       abuse reports after receipt if they do not have prior specific
       knowledge of the sender of the report.

       Report receivers MUST accept reports that have obscured their user-
       identifiable data as described in [RFC6590].  That document also
       discusses the handling of such reports.  This technique is also
       discussed in Section 4.4 of [RFC6449].

    4.6.  What to Do with Reports

       Section 4.3 of [RFC6449] discusses actions that mail operators might
       take upon receiving a report (or multiple reports).

    5.  Generating and Handling Unsolicited Abuse Reports

    5.1.  General Considerations

       It is essential for report recipients to be capable of throttling
       reports being sent to avoid damage to their own installations.
       Therefore, Feedback Providers MUST provide a way for report
       recipients to request that no further reports be sent.
       Unfortunately, no standardized mechanism for such requests exists to
       date, and all existing mechanisms for meeting this requirement are
       out-of-band.

       Message authentication is generally a good idea, but it is especially
       important to encourage credibility of, and thus response to,
       unsolicited reports.  Therefore, as with any other message, Feedback
       Providers sending unsolicited reports SHOULD send reports that they
       expect will pass the Sender Policy Framework (SPF) [RFC4408] and/or
       DomainKeys Identified Mail (DKIM) [RFC6376] checks.

    Falk & Kucherawy             Standards Track                    [Page 6]

    RFC 6650                         ARF AS                        June 2012

    5.2.  When to Generate Reports

       Handling of unsolicited reports has a significant cost to the report
       receiver.  Senders of unsolicited reports, especially those sending
       large volumes of them automatically, SHOULD NOT send reports that
       cannot be used as a basis for action by the recipient, whether this
       is due to the report being sent about an incident that is not abuse-
       related, the report being sent to an email address that won't result
       in action, or the content or format of the report being hard for the
       recipient to read or use.

       Feedback Providers SHOULD NOT report all mail sent from a particular
       sender merely because some of it is determined to be abusive.

       Mechanical reports of mail that "looks like" spam, based solely on
       the results of inline content analysis tools, SHOULD NOT be sent
       since, because of their subjective nature, they are unlikely to
       provide a basis for the recipient to take action.  Complaints
       generated by end users about mail that is determined by them to be
       abusive, or mail delivered to "spam trap" or "honeypot" addresses,
       are far more likely to be accurate and MAY be sent.

       If a Feedback Provider applies SPF [RFC4408] to arriving messages, a
       report SHOULD NOT be generated to the RFC5321.MailFrom domain if the
       SPF evaluation produced a "Fail", "SoftFail", "TempError", or
       "PermError" report, as no reliable assertion or assumption can be
       made that use of the domain was authorized.  A valid exception would
       be specific knowledge that the SPF result is not definitive for that
       domain under those circumstances (for example, a message that is also
       signed using DKIM [RFC6376] by the same domain, and that signature
       validates).

    5.3.  Where to Send Reports

       Rather than generating feedback reports themselves, MUAs SHOULD
       create abuse reports and send these reports back to their Mailbox
       Providers so that they can generate and send ARF messages on behalf
       of end users (see Section 3.2 of [RFC6449]).  This allows centralized
       processing and tracking of reports, and provides training input to
       filtering systems.  There is, however, no standard mechanism for this
       signaling between MUAs and Mailbox Providers to trigger abuse
       reports.

       Feedback Providers SHOULD NOT send reports to recipients that are
       uninvolved or only peripherally involved.  For example, they SHOULD
       NOT send reports to the operator of every Autonomous System in the
       path between the apparent originating system and the operator

    Falk & Kucherawy             Standards Track                    [Page 7]

    RFC 6650                         ARF AS                        June 2012

       generating the report.  Instead, they need to send reports to
       recipients that are both responsible for the messages and able to do
       something about them.

       Deciding where to send an unsolicited report will typically rely on
       heuristics.  Abuse addresses in WHOIS [RFC3912] records of the IP
       address relaying the subject message and/or of the domain name found
       in the results of a PTR ("reverse lookup") query on that address are
       likely reasonable candidates, as is the abuse@domain role address
       (see [RFC2142]) of related domains.  Unsolicited reports SHOULD NOT
       be sent to email addresses that are not clearly intended to handle
       abuse reports.  Legitimate candidates include those found in WHOIS
       records or on a web site that either are explicitly described as an
       abuse contact or are of the form "abuse@domain".

       Where an abusive message is authenticated using a domain-level
       authentication technology such as DKIM [RFC6376] or SPF [RFC4408],
       the domain that has been verified by the authentication mechanism is
       often a reasonable candidate for receiving feedback about the
       message.  For DKIM, though, while the authenticated domain has some
       responsibility for the mail sent, it can be a poor contact point for
       abuse issues (for example, it could represent the message's author
       but not its sender, it could identify the bad actor responsible for
       the message, or it could refer to a domain that cannot receive mail
       at all).

       Often, unsolicited reports will have no meaning if sent to abuse
       reporting addresses belonging to the abusive parties themselves.  In
       fact, it is possible that such reports might reveal information about
       complainants.  Reports SHOULD NOT be sent to such addresses if they
       can be identified beforehand, except where the abusive party is known
       to be responsive to such reports.

    5.4.  What to Put in Reports

       Reports SHOULD use "Feedback-Type: abuse" but can use other types as
       appropriate.  However, the Mailbox Provider generating the reports
       cannot assume that the operator receiving the reports will treat
       different Feedback-Types differently.

       Reports SHOULD include the following optional fields whenever their
       corresponding values are available and applicable to the report:
       Original-Mail-From, Arrival-Date, Source-IP, and Original-Rcpt-To.
       Other optional fields can be included as deemed appropriate by the
       implementer.

    Falk & Kucherawy             Standards Track                    [Page 8]

    RFC 6650                         ARF AS                        June 2012

       Experience suggests that the use of ARF is advisable in most
       contexts.  Automated recipient systems can handle abuse reports sent
       in ARF at least as well as any other format such as plain text, with
       or without a copy of the message attached.  That holds even for
       systems that did not request ARF reports, assuming such reports are
       generated considering the possibility of recipients that don't use
       automated ARF parsing.  Anyone sending unsolicited reports in ARF can
       legitimately presume that some recipients will only be able to access
       the human-readable (first, text/plain) part of it and SHOULD include
       all information needed also in this part.  Further, they SHOULD
       ensure that the report is readable when viewed as plain text, to give
       low-end ticketing systems as much assistance as possible.  In extreme
       cases, failure to take these steps may result in the report being
       discarded or ignored.

    5.5.  What to Do with Reports

       Receivers of unsolicited reports can take advantage of the
       standardized parts of ARF to automate processing.  Independent of the
       sender of the report, they can improve processing by separating valid
       reports from invalid reports by, for example, looking for references
       to IP address ranges, domains, and mailboxes for which the recipient
       organization is responsible in the copy of the reported message, and
       by correlating multiple reports of similar messages to identify bulk
       email senders.

       Per Section 4.4 of [RFC6449], a network service provider MAY use ARF
       data for automated forwarding of feedback messages to the originating
       customer.

       Published abuse mailbox addresses SHOULD NOT reject non-ARF messages
       based solely on the format, as generation of ARF messages can
       occasionally be unavailable or not applicable.  Deviation from this
       requirement could be done due to local policy decisions regarding
       other message criteria.

       Although [RFC6449] suggests that replying to feedback is not useful,
       in the case of receipt of ARF reports where no feedback arrangement
       has been established, a non-automated reply might be desirable to
       indicate what action resulted from the complaint, heading off more
       severe filtering by the Feedback Provider.  In addition, using an
       address that cannot receive replies precludes any requests for
       additional information and increases the likelihood that further
       reports will be discarded or blocked.  Thus, a Feedback Provider
       sending unsolicited reports SHOULD NOT generate reports for which a
       reply cannot be received.  Where an unsolicited report results in the
       establishment of contact with a responsible and responsive party,
       this data can be saved for future complaint handling and possible

    Falk & Kucherawy             Standards Track                    [Page 9]

    RFC 6650                         ARF AS                        June 2012

       establishment of a formal (solicited) feedback arrangement.  See
       Section 3.5 of [RFC6449] for a discussion of establishment of
       feedback arrangements.

    6.  Generating Automatic Authentication Failure Reports

       There are some cases where report generation is caused by automation
       rather than user requests.  A specific example of this is reporting,
       using ARF (or extensions to it), of messages that fail particular
       message authentication checks.  Examples of this include [RFC6651]
       and [RFC6652].  The considerations presented below apply in those
       cases.

       The applicability statement for this use case is somewhat smaller, as
       many of the issues associated with abuse reports are not relevant to
       reports about authentication failures.

       Automatic feedback generators MUST select actual message recipients
       based on data provided by willing report receivers.  In particular,
       recipients MUST NOT be selected using heuristics.

       If the message under evaluation by the Verifier is an ARF [RFC5965]
       message, a report MUST NOT be automatically generated.

       The message for a new report sent via SMTP MUST be constructed so as
       to avoid amplification attacks, deliberate or otherwise.  The
       envelope sender address of the report MUST be chosen so that these
       reports will not generate mail loops.  Similar to Section 2 of
       [RFC3464], the envelope sender address of the report MUST be chosen
       to ensure that no feedback reports will be issued in response to the
       report itself.  Therefore, when an SMTP transaction is used to send a
       report, the MAIL FROM command SHOULD use the NULL reverse-path, i.e.,
       "MAIL FROM:<>".  An exception to this would be the use of a reverse-
       path selected such that SPF checks on the report will pass; in such
       cases, the operator will need to make provisions to avoid the
       amplification attack or mail loop via other means.

       Reports SHOULD use "Feedback-Type: auth-failure" but MAY use other
       types as appropriate.  However, the Mailbox Provider generating the
       reports cannot assume that the operator receiving the reports will
       treat different Feedback-Types differently.

       These reports SHOULD include the following fields, although they are
       optional in [RFC5965], whenever their corresponding values are
       available: Original-Mail-From, Arrival-Date, Source-IP, and
       Original-Rcpt-To.  Other optional fields can be included as deemed
       appropriate by the implementer.

    Falk & Kucherawy             Standards Track                   [Page 10]

    RFC 6650                         ARF AS                        June 2012

    7.  Security Considerations

    7.1.  Security Considerations in Other Documents

       Implementers are strongly urged to review, at a minimum, the Security
       Considerations sections of [RFC5965] and [RFC6449].

    7.2.  Forgeries

       Feedback Providers that relay user complaints directly, rather than
       by reference to a stored message (e.g., IMAP or POP), could be duped
       into sending a complaint about a message that the complaining user
       never actually received, as an attack on the purported originator of
       the falsified message.  Feedback Providers need to be resilient to
       such attack methods.

       Also, these reports may be forged as easily as ordinary Internet
       electronic mail.  User agents and automatic mail handling facilities
       (such as mail distribution list exploders) that wish to make
       automatic use of reports of any kind should take appropriate
       precautions to minimize the potential damage from denial-of-service
       attacks.

       Perhaps the simplest means of mitigating this threat is to assert
       that these reports should themselves be signed with something like
       DKIM and/or authorized by something like SPF.  Note, however, that if
       there is a problem with the email infrastructure at either end, DKIM
       and/or SPF may result in reports that aren't trusted or even accepted
       by their intended recipients, so it is important to make sure those
       components are properly configured.  The use of both technologies in
       tandem can resolve this concern to a degree, since they generally
       have disjoint failure modes.

    7.3.  Amplification Attacks

       Failure to comply with the recommendations regarding selection of the
       envelope sender can lead to amplification denial-of-service attacks.
       This is discussed in Section 6 as well as in [RFC3464].

    7.4.  Automatic Generation

       ARF [RFC5965] reports have historically been generated individually
       as a result of some kind of human request, such as someone clicking a
       "Report Abuse" button in a mail reader.  In contrast, the mechanisms
       described in some extension documents (i.e., [RFC6651] and [RFC6652])
       are focused around automated reporting.  This obviously implies the

    Falk & Kucherawy             Standards Track                   [Page 11]

    RFC 6650                         ARF AS                        June 2012

       potential for much larger volumes or higher frequency of messages,
       and thus greater mail system load (both for Feedback Providers and
       report receivers).

       Those mechanisms are primarily intended for use in generating reports
       to aid implementers of DKIM [RFC6376], Author Domain Signing
       Practices (ADSP) [RFC5617], and SPF [RFC4408], and other related
       protocols during development and debugging.  They are not generally
       intended for prolonged forensic use, specifically because of these
       load concerns.  However, extended use is possible by ADministrative
       Management Domains (ADMDs) that want to keep a close watch for fraud
       or infrastructure problems.  It is important to consider the impact
       of doing so on both Feedback Providers and the requesting ADMDs.

       A sender requesting these reports can cause its mail servers to be
       overwhelmed if it sends out signed messages whose signatures fail to
       verify for some reason, provoking a large number of reports from
       Feedback Providers.  Similarly, a Feedback Provider could be
       overwhelmed by a large volume of messages requesting reports whose
       signatures fail to validate, as the Feedback Provider now needs to
       send reports back to the Signer.

       Limiting the rate of generation of these messages may be appropriate
       but threatens to inhibit the distribution of important and possibly
       time-sensitive information.

       In general ARF feedback loop terms, it is often suggested that
       Feedback Providers only create these (or any) ARF reports after an
       out-of-band arrangement has been made between two parties.  These
       extension mechanisms provide ways to adjust parameters of an
       authorized abuse report feedback loop that is configured and
       activated by private agreement.  The alternative (sending reports
       automatically based solely on data found in the messages) may have
       unintended consequences.

    7.5.  Reporting Multiple Incidents

       If it is known that a particular host generates abuse reports upon
       certain incidents, an attacker could forge a high volume of messages
       that will trigger such a report.  The recipient of the report could
       then be inundated with reports.  This could easily be extended to a
       distributed denial-of-service attack by finding a number of report-
       generating servers.

       The incident count referenced in ARF [RFC5965] provides a limited
       form of mitigation.  The host that generates reports can elect to
       send reports only periodically, with each report representing a
       number of identical or nearly identical incidents.  One might even do

    Falk & Kucherawy             Standards Track                   [Page 12]

    RFC 6650                         ARF AS                        June 2012

       something inverse-exponentially, sending reports for each of the
       first ten incidents, then every tenth incident up to 100, then every
       100th incident up to 1000, etc., until some period of relative quiet
       after which the limitation resets.

       The use of this technique for "nearly identical" incidents in
       particular causes a degradation in reporting quality, however.  If
       for example a large number of pieces of spam arrive from one
       attacker, a reporting agent could decide only to send a report about
       a fraction of those messages.  While this averts a flood of reports
       to a system administrator, the precise details of each incident are
       similarly not sent.

       Other rate-limiting provisions might be considered, such as detecting
       a temporary failure response from the report destination and thus
       halting report generation to that destination for some period, or
       simply imposing or negotiating a hard limit on the number of reports
       to be sent to a particular receiver in a given time frame.

    8.  Acknowledgements

       The author and editor wish to thank Steve Atkins, John Levine, Shmuel
       Metz, S. Moonesamy, and Alessandro Vesely for their contributions to
       this memo.

       All of the best practices referenced by this document are found in
       [RFC6449], written within the Collaboration Committee of the
       Messaging Anti-Abuse Working Group (MAAWG).

       Finally, the original author wishes to thank the doctors and staff
       at the University of Texas MD Anderson Cancer Center for doing what
       they do.

    9.  References

    9.1.  Normative References

       [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

       [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
                  October 2008.

       [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
                  October 2008.

       [RFC5598]  Crocker, D., "Internet Mail Architecture", RFC 5598,
                  July 2009.

    Falk & Kucherawy             Standards Track                   [Page 13]

    RFC 6650                         ARF AS                        June 2012

       [RFC5965]  Shafranovich, Y., Levine, J., and M. Kucherawy, "An
                  Extensible Format for Email Feedback Reports", RFC 5965,
                  August 2010.

       [RFC6591]  Fontana, H., "Authentication Failure Reporting Using the
                  Abuse Reporting Format", RFC 6591, April 2012.

    9.2.  Informative References

       [RFC1939]  Myers, J. and M. Rose, "Post Office Protocol - Version 3",
                  STD 53, RFC 1939, May 1996.

       [RFC2026]  Bradner, S., "The Internet Standards Process --
                  Revision 3", BCP 9, RFC 2026, October 1996.

       [RFC2142]  Crocker, D., "Mailbox Names for Common Services, Roles and
                  Functions", RFC 2142, May 1997.

       [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
                  Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
                  Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

       [RFC3464]  Moore, K. and G. Vaudreuil, "An Extensible Message Format
                  for Delivery Status Notifications", RFC 3464,
                  January 2003.

       [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
                  VERSION 4rev1", RFC 3501, March 2003.

       [RFC3912]  Daigle, L., "WHOIS Protocol Specification", RFC 3912,
                  September 2004.

       [RFC4408]  Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
                  for Authorizing Use of Domains in E-Mail, Version 1",
                  RFC 4408, April 2006.

       [RFC5617]  Allman, E., Fenton, J., Delany, M., and J. Levine,
                  "DomainKeys Identified Mail (DKIM) Author Domain Signing
                  Practices (ADSP)", RFC 5617, August 2009.

       [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
                  "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376,
                  September 2011.

       [RFC6430]  Li, K. and B. Leiba, "Email Feedback Report Type Value:
                  not-spam", RFC 6430, November 2011.

    Falk & Kucherawy             Standards Track                   [Page 14]

    RFC 6650                         ARF AS                        June 2012

       [RFC6449]  Falk, J., Ed., "Complaint Feedback Loop Operational
                  Recommendations", RFC 6449, November 2011.

       [RFC6590]  Falk, J., Ed., and M. Kucherawy, Ed., "Redaction of
                  Potentially Sensitive Data from Mail Abuse Reports",
                  RFC 6590, April 2012.

       [RFC6651]  Kucherawy, M., "Extensions to DomainKeys Identified Mail
                  (DKIM) for Failure Reporting", RFC 6651, June 2012.

       [RFC6652]  Kitterman, S., "Sender Policy Framework (SPF)
                  Authentication Failure Reporting Using the Abuse Reporting
                  Format", RFC 6652, June 2012.

    Authors' Addresses

       J.D. Falk
       Return Path
       100 Mathilda Place, Suite 100
       Sunnyvale, CA  94086
       USA

       URI:   http://www.returnpath.net/

       Murray S. Kucherawy (editor)
       Cloudmark
       128 King St., 2nd Floor
       San Francisco, CA  94107
       US

       EMail: superuser@gmail.com

    Falk & Kucherawy             Standards Track                   [Page 15]