doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc6650.txt b/doc/rfc/rfc6650.txt
new file mode 100644
index 0000000..9d9f2dc
--- /dev/null
+++ b/doc/rfc/rfc6650.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+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]
+