doc: Add RFC documents

1 files changed, 1403 insertions, 0 deletions

diff --git a/doc/rfc/rfc5965.txt b/doc/rfc/rfc5965.txt
new file mode 100644
index 0000000..7248bac
--- /dev/null
+++ b/doc/rfc/rfc5965.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                   Y. Shafranovich
+Request for Comments: 5965                           ShafTek Enterprises
+Category: Standards Track                                      J. Levine
+ISSN: 2070-1721                                     Taughannock Networks
+                                                            M. Kucherawy
+                                                               Cloudmark
+                                                             August 2010
+
+
+            An Extensible Format for Email Feedback Reports
+
+Abstract
+
+   This document defines an extensible format and MIME type that may be
+   used by mail operators to report feedback about received email to
+   other parties.  This format is intended as a machine-readable
+   replacement for various existing report formats currently used in
+   Internet email.
+
+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/rfc5965.
+
+Copyright Notice
+
+   Copyright (c) 2010 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.
+
+
+
+
+Shafranovich, et al.         Standards Track                    [Page 1]
+
+RFC 5965               Format for Feedback Reports           August 2010
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Purpose ....................................................3
+      1.2. Requirements ...............................................4
+      1.3. Definitions ................................................4
+           1.3.1. General .............................................4
+           1.3.2. Email Specific ......................................4
+   2. Format of Email Feedback Reports ................................4
+   3. The 'message/feedback-report' Content Type ......................5
+      3.1. Required Fields ............................................6
+      3.2. Optional Fields Appearing Once .............................6
+      3.3. Optional Fields Appearing Multiple Times ...................7
+      3.4. Notes about URIs ...........................................8
+      3.5. Formal Definition ..........................................8
+   4. Handling Malformed Reports .....................................10
+   5. Transport Considerations .......................................10
+   6. Extensibility ..................................................10
+   7. IANA Considerations ............................................11
+      7.1. MIME Type Registration of 'message/feedback-report' .......11
+      7.2. Feedback Report Header Fields .............................12
+      7.3. Feedback Report Type Values ...............................15
+   8. Security Considerations ........................................17
+      8.1. Inherited from RFC 3462 ...................................17
+      8.2. Interpretation ............................................17
+      8.3. Attacks against Authentication Methods ....................17
+      8.4. Intentionally Malformed Reports ...........................18
+      8.5. Omitting Data from ARF Reports ............................18
+      8.6. Automatically Generated ARF Reports .......................18
+      8.7. Attached Malware ..........................................18
+      8.8. The User-Agent Field ......................................18
+      8.9. Malformed Messages ........................................19
+   9. References .....................................................19
+      9.1. Normative References ......................................19
+      9.2. Informative References ....................................20
+   Appendix A.  Acknowledgements .....................................22
+   Appendix B.  Sample Feedback Reports ..............................22
+      B.1.  Simple Report for Email Abuse without Optional Headers ...22
+      B.2.  Full Report for Email Abuse with All Headers .............23
+
+
+
+
+
+
+
+
+
+
+
+
+Shafranovich, et al.         Standards Track                    [Page 2]
+
+RFC 5965               Format for Feedback Reports           August 2010
+
+
+1.  Introduction
+
+   As the spam problem continues to expand and potential solutions
+   evolve, mail operators are increasingly exchanging abuse reports
+   among themselves and other parties.  However, different operators
+   have defined their own formats, and thus the receivers of these
+   reports are forced to write custom software to interpret each of
+   them.  In addition, many operators use various other report formats
+   to provide non-abuse-related feedback about processed email.  This
+   memo uses the "multipart/report" content type defined in [REPORT],
+   and in that context defines a standard extensible format by creating
+   the "message/feedback-report" [MIME] type for these reports.
+
+   While there has been previous work in this area (e.g., [STRADS-BCP]
+   and [ASRG-ABUSE]), none of it has yet been successful.  It is hoped
+   that this document will have a better fate.
+
+   This format is intended primarily as an Abuse Reporting Format (ARF)
+   for reporting email abuse but also includes support for direct
+   feedback via end user mail clients, reports of some types of virus
+   activity, and some similar issues.  This memo also contains provision
+   for extensions should other specific types of reports be desirable in
+   the future.
+
+   This document only defines the format and [MIME] content type to be
+   used for these reports.  Determination of where these reports should
+   be sent, validation of their contents, and how trust among report
+   generators and report recipients is established are outside the scope
+   of this document.  It is assumed that best practices will evolve over
+   time, and will be codified in future documents.
+
+1.1.  Purpose
+
+   The reports defined in this document are intended to inform mail
+   operators about:
+
+   o  email abuse originating from their networks;
+
+   o  potential issues with the perceived quality of outbound mail, such
+      as email service providers sending mail that attracts the
+      attention of automated abuse detection systems.
+
+   Please note that while the parent "multipart/report" content type
+   defined in [REPORT] is used for all kinds of administrative messages,
+   this format is intended specifically for communications among
+   providers regarding email abuse and related issues, and SHOULD NOT be
+   used for other reports.
+
+
+
+
+Shafranovich, et al.         Standards Track                    [Page 3]
+
+RFC 5965               Format for Feedback Reports           August 2010
+
+
+1.2.  Requirements
+
+   The following requirements are necessary for feedback reports (the
+   actual specification is defined later in this document):
+
+   o  They must be both human and machine readable;
+
+   o  A copy of the original email message (both body and header) or the
+      message header must be enclosed in order to allow the receiver to
+      handle the report properly;
+
+   o  The machine-readable section must provide ability for the report
+      generators to share meta-data with receivers;
+
+   o  The format must be extensible.
+
+1.3.  Definitions
+
+   This section defines various terms used throughout this document.
+
+1.3.1.  General
+
+   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 [KEYWORDS].
+
+1.3.2.  Email Specific
+
+   [EMAIL-ARCH] introduces several terms and concepts that are used in
+   this memo, and thus readers are advised to become familiar with it as
+   well.
+
+2.  Format of Email Feedback Reports
+
+   To satisfy the requirements, an email feedback report is defined as a
+   [MIME] message with a top-level MIME content type of "multipart/
+   report" (as defined in [REPORT]).  The following apply:
+
+   a.  The "report-type" parameter of the "multipart/report" type is set
+       to "feedback-report";
+
+   b.  The first MIME part of the message contains a human-readable
+       description of the report and MUST be included.
+
+
+
+
+
+
+
+
+Shafranovich, et al.         Standards Track                    [Page 4]
+
+RFC 5965               Format for Feedback Reports           August 2010
+
+
+   c.  The second MIME part of the message is a machine-readable section
+       with the content type of "message/feedback-report" (defined later
+       in this memo) and MUST be included.  This section is intended to
+       convey meta-data about the report in question that may not be
+       readily available from the included email message itself.
+
+   d.  The third MIME part of the message is either of type "message/
+       rfc822" (as defined in [MIME-TYPES]) and contains the original
+       message in its entirety OR is of type "text/rfc822-headers" (as
+       defined in [REPORT]) and contains a copy of the entire header
+       block from the original message.  This part MUST be included
+       (contrary to [REPORT]).  While some operators may choose to
+       modify or redact this portion for privacy or legal reasons, it is
+       RECOMMENDED that the entire original email message be included
+       without any modification as such modifications can impede
+       forensic work by the recipient of this report.  See Section 8 for
+       further discussion.
+
+   e.  Except as discussed below, each feedback report MUST be related
+       to only a single email message.  Summary and aggregate formats
+       are outside of the scope of this specification.
+
+   f.  The Subject header field of the feedback report SHOULD be the
+       same as the included email message about which the report is
+       being generated.  If it differs, the difference MUST be limited
+       to only a typical forwarding prefix used by Mail User Agents
+       (MUAs) such as "FW:".  (Many smaller operators using MUAs for
+       abuse handling rely on the subject lines for processing.)
+
+   g.  The primary evidence of the abuse being reported is found in the
+       third part of the report, which contains the original message.
+       The second part contains additional derived data that may help
+       the receiver, but in terms of selecting actionable report data,
+       report recipients SHOULD use the content of the third part first,
+       then data from the second part.  The first part is meant to
+       contain explanatory text for human use but is not itself a part
+       of the report, and SHOULD NOT be used if it is in conflict with
+       the other parts.
+
+3.  The 'message/feedback-report' Content Type
+
+   A new [MIME] content type called "message/feedback-report" is
+   defined.  This content type provides a machine-readable section
+   intended to let the report generator convey meta-data to the report
+   receiver.  The intent of this section is to convey information that
+   may not be obvious or may not be easily extracted from the original
+   email message body or header.
+
+
+
+
+Shafranovich, et al.         Standards Track                    [Page 5]
+
+RFC 5965               Format for Feedback Reports           August 2010
+
+
+   The body of this content type consists of multiple "fields" formatted
+   according to the ABNF of [MAIL] header fields.  This section defines
+   the initial set of fields provided by this specification.  Additional
+   fields may be registered according to the procedure described later
+   in this memo.  Although these fields have a syntax similar to those
+   of mail message header fields, they are semantically distinct; hence,
+   they SHOULD NOT be repeated as header fields of the message
+   containing the report.  Note that these fields represent information
+   that the receiver is asserting about the report in question, but are
+   not necessarily verifiable.  Report receivers MUST NOT assume that
+   these assertions are always accurate.
+
+   Note that the above limitation in no way restricts the use of message
+   header fields that are registered in the IANA header field registry
+   with the same field names.
+
+3.1.  Required Fields
+
+   The following report header fields MUST appear exactly once:
+
+   o  "Feedback-Type" contains the type of feedback report (as defined
+      in the corresponding IANA registry and later in this memo).  This
+      is intended to let report parsers distinguish among different
+      types of reports.
+
+   o  "User-Agent" indicates the name and version of the software
+      program that generated the report.  The format of this field MUST
+      follow section 14.43 of [HTTP].  This field is for documentation
+      only; there is no registry of user agent names or versions, and
+      report receivers SHOULD NOT expect user agent names to belong to a
+      known set.
+
+   o  "Version" indicates the version of specification that the report
+      generator is using to generate the report.  The version number in
+      this specification is set to "1".
+
+3.2.  Optional Fields Appearing Once
+
+   The following header fields are optional and MUST NOT appear more
+   than once:
+
+   o  "Original-Envelope-Id" contains the envelope ID string used in the
+      original [SMTP] transaction (see section 2.2.1 of [DSN]).
+
+   o  "Original-Mail-From" contains a copy of the email address used in
+      the MAIL FROM portion of the original SMTP transaction.  The
+      format of this field is defined in section 4.1.2 of [SMTP] as
+      "Reverse-path".
+
+
+
+Shafranovich, et al.         Standards Track                    [Page 6]
+
+RFC 5965               Format for Feedback Reports           August 2010
+
+
+   o  "Arrival-Date" indicates the date and time at which the original
+      message was received by the Mail Transfer Agent (MTA) of the
+      generating ADMD (Administrative Management Domain).  This field
+      MUST be formatted as per section 3.3 of [MAIL].
+
+   o  "Reporting-MTA" indicates the name of the MTA generating this
+      feedback report.  This field is defined in section 2.2.2 of [DSN],
+      except that it is an optional field in this report.
+
+   o  "Source-IP" contains an IPv4 or IPv6 address of the MTA from which
+      the original message was received.  Addresses MUST be formatted as
+      per section 4.1.3 of [SMTP].
+
+   o  "Incidents" contains an unsigned 32-bit integer indicating the
+      number of incidents this report represents.  The absence of this
+      field implies the report covers a single incident.
+
+   The historic field "Received-Date" SHOULD also be accepted and
+   interpreted identically to "Arrival-Date".  However, if both are
+   present, the report is malformed and SHOULD be treated as described
+   in Section 4.
+
+3.3.  Optional Fields Appearing Multiple Times
+
+   The following set of header fields are optional and may appear any
+   number of times as appropriate:
+
+   o  "Authentication-Results" indicates the result of one or more
+      authentication checks run by the report generator.  The format of
+      this field is defined in [AUTH-RESULTS].  Report receivers should
+      note that this field only indicates an assertion made by the
+      report generator.
+
+   o  "Original-Rcpt-To" includes a copy of the email address used in
+      the RCPT TO portion of the original [SMTP] transaction.  The
+      format of this field is a "Reverse-path" defined in section 4.1.2
+      of that memo.  This field SHOULD be repeated for every SMTP
+      recipient seen by the report generator.
+
+   o  "Reported-Domain" includes a domain name that the report generator
+      believes to be relevant to the report, e.g., the domain whose
+      apparent actions provoked the generation of the report.  It is
+      unspecified how the report generator determines this information,
+      and thus the report receiver cannot be certain how it was chosen.
+      It is often used as a means of suggesting to the report receiver
+      how this report might be handled.  In cases where the derivation
+
+
+
+
+
+Shafranovich, et al.         Standards Track                    [Page 7]
+
+RFC 5965               Format for Feedback Reports           August 2010
+
+
+      is not obvious, the report generator is encouraged to clarify in
+      the text section of the report.  Domain format is defined in
+      section 2.3.1 of [DNS].
+
+   o  "Reported-URI" indicates a URI that the report generator believes
+      to be relevant to the report, e.g., a suspect URI that was found
+      in the message that caused the report to be generated.  The same
+      caveats about the origin of the value of "Reported-Domain" apply
+      to this field.  The URI format is defined in [URI].
+
+3.4.  Notes about URIs
+
+   Implementors should be aware that the Reported-URI field can carry
+   many different types of data depending on the URI scheme used.  For
+   more information, please consult the "URI Schemes" registry
+   maintained by IANA.
+
+   Furthermore, it is outside the scope of this standard whether the
+   data carried in this field implies any additional information.
+   Implementors may negotiate their own agreements surrounding the
+   interpretation of this data.
+
+3.5.  Formal Definition
+
+   The formal definition of the contents of a "message/feedback-report"
+   media type using [ABNF] is as follows:
+
+   feedback-report = *( feedback-type / user-agent / version )
+                     opt-fields-once
+                     *( opt-fields-many )
+                     *( ext-field )
+
+   feedback-type = "Feedback-Type:" [CFWS] token [CFWS] CRLF
+       ; the "token" must be a registered feedback type as
+       ; described elsewhere in this document
+
+   user-agent = "User-Agent:" [CFWS] product *( CFWS product )
+                [CFWS] CRLF
+
+   version = "Version:" [CFWS] %x31-39 *DIGIT [CFWS] CRLF
+       ; as described above
+
+   opt-fields-once = [ arrival-date ]
+                     [ incidents ]
+                     [ original-envelope-id ]
+                     [ original-mail-from ]
+                     [ reporting-mta ]
+                     [ source-ip ]
+
+
+
+Shafranovich, et al.         Standards Track                    [Page 8]
+
+RFC 5965               Format for Feedback Reports           August 2010
+
+
+   arrival-date = "Arrival-Date:" [CFWS] date-time CRLF
+
+   incidents = "Incidents:" [CFWS] 1*DIGIT [CFWS] CRLF
+             ; must be a 32-bit unsigned integer
+
+   original-envelope-id = "Original-Envelope-Id:" [CFWS]
+                          envelope-id [CFWS] CRLF
+
+   original-mail-from = "Original-Mail-From:" [CFWS]
+                        reverse-path [CFWS] CRLF
+
+   reporting-mta = "Reporting-MTA:" [CFWS] mta-name-type [CFWS] ";"
+                   [CFWS] mta-name [CFWS] CRLF
+
+   source-ip = "Source-IP:" [CFWS]
+               ( IPv4-address-literal /
+                 IPv6-address-literal ) [CFWS] CRLF
+
+   opt-fields-many = [ authres-header ]
+                     [ original-rcpt-to ]
+                     [ reported-domain ]
+                     [ reported-uri ]
+
+   original-rcpt-to = "Original-Rcpt-To:" [CFWS]
+                      forward-path [CFWS] CRLF
+
+   reported-domain = "Reported-Domain:" [CFWS]
+                     domain [CFWS] CRLF
+
+   reported-uri = "Reported-URI:" [CFWS] URI [CFWS] CRLF
+
+   ext-field = field-name ":" unstructured
+
+   A set of fields satisfying this ABNF may appear in the transmitted
+   message in any order.
+
+   "CRLF" and "DIGIT" are imported from [ABNF].
+
+   "token" is imported from [MIME].
+
+   "product" is imported from [HTTP].
+
+   "field-name", "unstructured", "CFWS", "date-time", and "domain" are
+   imported from [MAIL].
+
+   "envelope-id", "mta-name-type", and "mta-name" are imported from
+   [DSN].
+
+
+
+
+Shafranovich, et al.         Standards Track                    [Page 9]
+
+RFC 5965               Format for Feedback Reports           August 2010
+
+
+   "reverse-path", "forward-path", "local-part", "IPv4-address-literal",
+   and "IPv6-address-literal" are imported from [SMTP].
+
+   "URI" is imported from [URI].
+
+   "authres-header" is imported from [AUTH-RESULTS].
+
+   "ext-field" refers to extension fields, which are discussed in
+   Section 6.
+
+4.  Handling Malformed Reports
+
+   When an agent that accepts and handles ARF messages receives a
+   message that purports (by MIME type) to be an ARF message but
+   syntactically deviates from this specification, that agent SHOULD
+   ignore or reject the message.  Where rejection is performed, the
+   rejection notice (either via an [SMTP] reply or generation of a
+   [DSN]) SHOULD identify the specific cause for the rejection.
+
+   See Section 8.9 for further discussion.
+
+5.  Transport Considerations
+
+   [DSN] requires that its reports be sent with the empty [SMTP]
+   envelope sender to avoid bounce loops.  A similar requirement was
+   considered for this specification, but it seems unlikely that an ARF
+   report would be generated in response to receipt of an ARF report,
+   and furthermore such a requirement would prevent an ARF generator
+   from ever determining that an ARF report was not actually received.
+
+   On the other hand, if an ARF report is generated without the empty
+   envelope sender and is sent to an address that actually does not
+   work, then the generating address can also be overwhelmed by DSNs as
+   a denial-of-service attack (see Section 8.6).
+
+   This specification therefore makes no requirement related to the
+   envelope sender of a generated report.  Operators will have to
+   consider what envelope sender to use within the context of their own
+   installations.
+
+6.  Extensibility
+
+   Like many other formats and protocols, this format may need to be
+   extended over time to fit the ever-changing landscape of the
+   Internet.  Therefore, extensibility is provided via two IANA
+   registries: one for feedback types and a second for report header
+   fields.  The feedback type registry is to be used in conjunction with
+   the "Feedback-Type" field above.  The header name registry is
+
+
+
+Shafranovich, et al.         Standards Track                   [Page 10]
+
+RFC 5965               Format for Feedback Reports           August 2010
+
+
+   intended for registration of new meta-data fields to be used in the
+   machine-readable portion (part 2) of this format.  Please note that
+   version numbers do not change with new field registrations unless a
+   new specification of this format is published.  Also, note that all
+   new field registrations may only be registered as optional fields.
+   Any new required fields REQUIRE a new version of this specification
+   to be published.
+
+   In order to encourage extensibility and interoperability of this
+   format, implementors MUST ignore any fields or report types they do
+   not explicitly support.
+
+   Additional report types (extension report types) or report header
+   fields might be defined in the future by later revisions to this
+   specification, or by registrations as described above.  Such types
+   and fields MUST be registered as described above and published in an
+   Open Specification such as an RFC.
+
+   Experimental report types and report header fields MUST only be used
+   between ADMDs that have explicitly consented to use them.  These
+   names and the parameters associated with them are not documented in
+   RFCs.  Therefore, they are subject to change at any time and are not
+   suitable for general use.
+
+7.  IANA Considerations
+
+   IANA has registered a new [MIME] type and created two new registries,
+   as described below.
+
+7.1.  MIME Type Registration of 'message/feedback-report'
+
+   This section provides the media type registration application from
+   [MIME-REG] for processing by IANA:
+
+   To:  ietf-types@iana.org
+
+   Subject:  Registration of media type message/feedback-report
+
+   Type name:  message
+
+   Subtype name:  feedback-report
+
+   Required parameters:  none
+
+   Optional parameters:  none
+
+   Encoding considerations:  "7bit" encoding is sufficient and MUST be
+      used to maintain readability when viewed by non-MIME mail readers.
+
+
+
+Shafranovich, et al.         Standards Track                   [Page 11]
+
+RFC 5965               Format for Feedback Reports           August 2010
+
+
+   Security considerations:  See Section 8 of [RFC5965].
+
+   Interoperability considerations:  Implementors MUST ignore any fields
+      they do not support.
+
+   Published specification:  [RFC5965]
+
+   Applications that use this media type:  Abuse helpdesk software for
+      ISPs, mail service bureaus, mail certifiers, and similar
+      organizations
+
+   Additional information:  none
+
+   Person and email address to contact for further information:
+
+         Yakov Shafranovich <ietf@shaftek.org>
+
+         Murray S. Kucherawy <msk@cloudmark.com>
+
+   Intended usage:  COMMON
+
+   Author:
+
+         Yakov Shafranovich
+
+         John R. Levine
+
+         Murray S. Kucherawy
+
+   Change controller:  IESG
+
+7.2.  Feedback Report Header Fields
+
+   IANA has created the "Feedback Report Header Fields" registry.  This
+   registry contains header fields for use in feedback reports, as
+   defined by this memo.
+
+   New registrations or updates MUST be published in accordance with the
+   "Specification Required" guidelines as described in [IANA].  Any new
+   field thus registered is considered optional by this specification
+   unless a new version of this memo is published.
+
+   New registrations and updates MUST contain the following information:
+
+   1.  Name of the field being registered or updated
+
+   2.  Short description of the field
+
+
+
+
+Shafranovich, et al.         Standards Track                   [Page 12]
+
+RFC 5965               Format for Feedback Reports           August 2010
+
+
+   3.  Whether the field can appear more than once
+
+   4.  To which feedback type(s) this field applies (or "any")
+
+   5.  The document in which the specification of the field is published
+
+   6.  New or updated status, which MUST be one of:
+
+       current:  The field is in current use
+
+       deprecated:  The field is in current use but its use is
+          discouraged
+
+       historic:  The field is no longer in current use
+
+   An update may make a notation on an existing registration indicating
+   that a registered field is historic or deprecated if appropriate.
+
+   The initial registry contains these values:
+
+       Field Name: Arrival-Date
+       Description: date/time the original message was received
+       Multiple Appearances: No
+       Related "Feedback-Type": any
+       Published in: [RFC5965]
+       Status: current
+
+
+       Field Name: Authentication-Results
+       Description: results of authentication check(s)
+       Multiple Appearances: Yes
+       Related "Feedback-Type": any
+       Published in: [RFC5965]
+       Status: current
+
+
+       Field Name: Feedback-Type
+       Description: registered feedback report type
+       Multiple Appearances: No
+       Related "Feedback-Type": N/A
+       Published in: [RFC5965]
+       Status: current
+
+
+
+
+
+
+
+
+
+Shafranovich, et al.         Standards Track                   [Page 13]
+
+RFC 5965               Format for Feedback Reports           August 2010
+
+
+       Field Name: Incidents
+       Description: expression of how many similar incidents are
+                    represented by this report
+       Multiple Appearances: No
+       Related "Feedback-Type": any
+       Published in: [RFC5965]
+       Status: current
+
+
+       Field Name: Original-Mail-From
+       Description: email address used in the MAIL FROM portion of the
+                    original SMTP transaction
+       Multiple Appearances: No
+       Related "Feedback-Type": any
+       Published in: [RFC5965]
+       Status: current
+
+
+       Field Name: Original-Rcpt-To
+       Description: email address used in the RCPT TO portion of the
+                    original SMTP transaction
+       Multiple Appearances: Yes
+       Related "Feedback-Type": any
+       Published in: [RFC5965]
+       Status: current
+
+
+       Field Name: Received-Date
+       Description: date/time the original message was received
+                    (replaced by "Arrival-Date")
+       Multiple Appearances: No
+       Related "Feedback-Type": any
+       Published in: [RFC5965]
+       Status: historic
+
+
+       Field Name: Reported-Domain
+       Description: a domain name the report generator considers to
+                    be key to the message about which a report is
+                    being generated
+       Multiple Appearances: Yes
+       Related "Feedback-Type": any
+       Published in: [RFC5965]
+       Status: current
+
+
+
+
+
+
+
+Shafranovich, et al.         Standards Track                   [Page 14]
+
+RFC 5965               Format for Feedback Reports           August 2010
+
+
+       Field Name: Reported-URI
+       Description: a URI the report generator considers to be key
+                    to the message about which a report is being
+                    generated
+       Multiple Appearances: Yes
+       Related "Feedback-Type": any
+       Published in: [RFC5965]
+       Status: current
+
+
+       Field Name: Reporting-MTA
+       Description: MTA generating this report
+       Multiple Appearances: No
+       Related "Feedback-Type": any
+       Published in: [RFC5965]
+       Status: current
+
+
+       Field Name: Source-IP
+       Description: IPv4 or IPv6 address from which the original message
+                    was received
+       Multiple Appearances: No
+       Related "Feedback-Type": any
+       Published in: [RFC5965]
+       Status: current
+
+
+       Field Name: User-Agent
+       Description: name and version of the program generating the
+                    report
+       Multiple Appearances: No
+       Related "Feedback-Type": any
+       Published in: [RFC5965]
+       Status: current
+
+
+       Field Name: Version
+       Description: version of specification used
+       Multiple Appearances: No
+       Related "Feedback-Type": any
+       Published in: [RFC5965]
+       Status: current
+
+7.3.  Feedback Report Type Values
+
+   IANA has created the "Feedback Report Type Values" registry.  This
+   registry contains feedback types for use in feedback reports, defined
+   by this memo.
+
+
+
+Shafranovich, et al.         Standards Track                   [Page 15]
+
+RFC 5965               Format for Feedback Reports           August 2010
+
+
+   New registrations or updates MUST be published in accordance with the
+   "Specification Required" guidelines as described in [IANA].  Any new
+   field thus registered is considered optional by this specification
+   unless a new version of this memo is published.
+
+   New registrations MUST contain the following information:
+
+   1.  Name of the feedback type being registered
+
+   2.  Short description of the feedback type
+
+   3.  The document in which the specification of the field is published
+
+   4.  New or updated status, which MUST be one of:
+
+       current:  The field is in current use
+
+       deprecated:  The field is in current use but its use is
+          discouraged
+
+       historic:  The field is no longer in current use
+
+   The initial registry contains these values:
+
+       Feedback Type Name: abuse
+       Description: unsolicited email or some other kind of email abuse
+       Published in: [RFC5965]
+       Status: current
+
+
+       Feedback Type Name: fraud
+       Description: indicates some kind of fraud or phishing activity
+       Published in: [RFC5965]
+       Status: current
+
+
+       Feedback Type Name: other
+       Description: any other feedback that does not fit into other
+                    registered types
+       Published in: [RFC5965]
+       Status: current
+
+
+       Feedback Type Name: virus
+       Description: report of a virus found in the originating message
+       Published in: [RFC5965]
+       Status: current
+
+
+
+
+Shafranovich, et al.         Standards Track                   [Page 16]
+
+RFC 5965               Format for Feedback Reports           August 2010
+
+
+8.  Security Considerations
+
+   The following security considerations apply when generating or
+   processing a feedback report:
+
+8.1.  Inherited from RFC 3462
+
+   All of the Security Considerations from [REPORT] are inherited here.
+
+8.2.  Interpretation
+
+   This specification describes a report format.  The authentication and
+   validity of the content of the report SHOULD be established through
+   other means.  The content of an unvetted report could be wrong,
+   incomplete or deliberately false, including the alleged abuse
+   incident in the third part, derived data in the second part or the
+   human-readable first part.
+
+   There will be some desire to perform some actions in an automated
+   fashion in order to enact timely responses to common feedback
+   reports.  Caution must be taken, however, as there is no substantial
+   security around the content of these reports.  An attacker could
+   craft a report meant to generate undesirable actions on the part of a
+   report recipient.
+
+   It is suggested that the origin of an ARF report be vetted, such as
+   by using common message authentication schemes like [SMIME], [DKIM],
+   [SPF], or [SENDERID], prior to the undertaking of any kind of
+   automated action in response to receipt of the report.  In
+   particular, S/MIME offers the strongest authentication and the cost
+   of key exchange is assumed in the process of establishing a bilateral
+   reporting relationship that uses this specification; however, it is
+   not as transparent as the others and thus will interfere with the
+   parsing capabilities of code that is designed specifically to handle
+   multipart/report messages.
+
+   The details of the required validation to achieve this are a matter
+   of local policy and are thus outside the scope of this specification.
+
+8.3.  Attacks against Authentication Methods
+
+   If an attack becomes known against an authentication method, clearly
+   then the agent verifying that method can be fooled into thinking an
+   inauthentic message is authentic, and thus the value of this header
+   field can be misleading.  It follows that any attack against an
+   authentication method that might be used to protect the authenticity
+   of an abuse report is also a security consideration here.
+
+
+
+
+Shafranovich, et al.         Standards Track                   [Page 17]
+
+RFC 5965               Format for Feedback Reports           August 2010
+
+
+8.4.  Intentionally Malformed Reports
+
+   It is possible for an attacker to generate an ARF message field that
+   is extraordinarily large or otherwise malformed in an attempt to
+   discover or exploit weaknesses in recipient parsing code.
+   Implementors SHOULD thoroughly verify all such messages and be robust
+   against intentionally as well as unintentionally malformed messages.
+
+8.5.  Omitting Data from ARF Reports
+
+   The sending of these reports can reveal possibly private information
+   about the person sending the report.  For example, such a report sent
+   in response to a mailing list posting will reveal to the report
+   recipient a valid email address on the list that might otherwise have
+   remained hidden.
+
+   For this reason, report generators might wish to redact portions of
+   the report to conceal private information.  Doing so could be
+   necessary where privacy trumps operational necessity, but, as
+   mentioned in Section 2, it might impede a timely or meaningful
+   response from the report recipient.
+
+8.6.  Automatically Generated ARF Reports
+
+   Systems have been implemented that generate ARF reports automatically
+   in response to an event.  For example, software monitoring a honeypot
+   email address might generate an ARF report immediately upon delivery
+   of any message to it.  An attacker that becomes aware of such a
+   configuration can exploit it to attack an ARF recipient with
+   automatically generated ARF reports.
+
+8.7.  Attached Malware
+
+   As this format is sometimes used to automatically report malware, ARF
+   processors (human or otherwise) SHOULD ensure that attachments are
+   processed in a manner appropriate for unverified and potentially
+   hostile data.
+
+8.8.  The User-Agent Field
+
+   Further to Section 8.2, the User-Agent field is an assertion of the
+   generating software and is neither specified in this memo nor derived
+   from the message represented in the third part of the report.  It is
+   intended for documentation and debugging, and since it is trivially
+   forged by a malicious agent, it SHOULD NOT be interpreted by
+   recipients.
+
+
+
+
+
+Shafranovich, et al.         Standards Track                   [Page 18]
+
+RFC 5965               Format for Feedback Reports           August 2010
+
+
+8.9.  Malformed Messages
+
+   Further to the discussion in Section 4, there might be cases where an
+   ARF processing agent elects to accept messages not consistent with
+   this specification, such as during transition periods where some
+   fields are moving toward "historic" or "deprecated" status, or the
+   introduction of new non-standard extension or experimental fields.
+   Such choices need to be implemented with extreme caution; where two
+   different fields have related meaning (e.g., "Received-Date", which
+   is historic, and "Arrival-Date", which is current), an attacker could
+   craft a report that makes a confusing claim in an attempt to exploit
+   such liberal parsing logic.
+
+9.  References
+
+9.1.  Normative References
+
+   [ABNF]          Crocker, D. and P. Overell, "Augmented BNF for Syntax
+                   Specifications: ABNF", STD 68, RFC 5234,
+                   January 2008.
+
+   [AUTH-RESULTS]  Kucherawy, M., "Message Header Field for Indicating
+                   Message Authentication Status", RFC 5451, April 2009.
+
+   [DNS]           Mockapetris, P., "Domain names - implementation and
+                   specification", STD 13, RFC 1035, November 1987.
+
+   [DSN]           Moore, K. and G. Vaudreuil, "An Extensible Message
+                   Format for Delivery Status Notifications", RFC 3464,
+                   January 2003.
+
+   [HTTP]          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.
+
+   [KEYWORDS]      Bradner, S., "Key words for use in RFCs to Indicate
+                   Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [MAIL]          Resnick, P., Ed., "Internet Message Format",
+                   RFC 5322, October 2008.
+
+   [MIME]          Freed, N. and N. Borenstein, "Multipurpose Internet
+                   Mail Extensions (MIME) Part One: Format of Internet
+                   Message Bodies", RFC 2045, November 1996.
+
+
+
+
+
+
+Shafranovich, et al.         Standards Track                   [Page 19]
+
+RFC 5965               Format for Feedback Reports           August 2010
+
+
+   [MIME-REG]      Freed, N. and J. Klensin, "Media Type Specifications
+                   and Registration Procedures", BCP 13, RFC 4288,
+                   December 2005.
+
+   [MIME-TYPES]    Freed, N. and N. Borenstein, "Multipurpose Internet
+                   Mail Extensions (MIME) Part Two: Media Types",
+                   RFC 2046, November 1996.
+
+   [REPORT]        Vaudreuil, G., "The Multipart/Report Content Type for
+                   the Reporting of Mail System Administrative
+                   Messages", RFC 3462, January 2003.
+
+   [SMTP]          Klensin, J., "Simple Mail Transfer Protocol",
+                   RFC 5321, October 2008.
+
+   [URI]           Berners-Lee, T., Fielding, R., and L. Masinter,
+                   "Uniform Resource Identifier (URI): Generic Syntax",
+                   STD 66, RFC 3986, January 2005.
+
+9.2.  Informative References
+
+   [ASRG-ABUSE]    Anti-Spam Research Group (ASRG) of the Internet
+                   Research Task Force (IRTF), "Abuse Reporting
+                   Standards Subgroup of the ASRG", May 2005.
+
+   [DKIM]          Allman, E., Callas, J., Delany, M., Libbey, M.,
+                   Fenton, J., and M. Thomas, "DomainKeys Identified
+                   Mail (DKIM) Signatures", RFC 4871, May 2007.
+
+   [EMAIL-ARCH]    Crocker, D., "Internet Mail Architecture", RFC 5598,
+                   July 2009.
+
+   [IANA]          Narten, T. and H. Alvestrand, "Guidelines for Writing
+                   an IANA Considerations Section in RFCs", BCP 26,
+                   RFC 5226, May 2008.
+
+   [SENDERID]      Lyon, J. and M. Wong, "Sender ID: Authenticating
+                   E-Mail", RFC 4406, April 2006.
+
+   [SMIME]         Ramsdell, B. and S. Turner, "Secure/Multipurpose
+                   Internet Mail Extensions (S/MIME) Version 3.2 Message
+                   Specification", RFC 5751, January 2010.
+
+   [SPF]           Wong, M. and W. Schlitt, "Sender Policy Framework
+                   (SPF) for Authorizing Use of Domains in E-Mail,
+                   Version 1", RFC 4408, April 2006.
+
+
+
+
+
+Shafranovich, et al.         Standards Track                   [Page 20]
+
+RFC 5965               Format for Feedback Reports           August 2010
+
+
+   [STRADS-BCP]    Crissman, G., "Proposed Spam Reporting BCP Document",
+                   May 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Shafranovich, et al.         Standards Track                   [Page 21]
+
+RFC 5965               Format for Feedback Reports           August 2010
+
+
+Appendix A.  Acknowledgements
+
+   The authors would like to thank many of the members of the email
+   community who provided helpful comments and suggestions for this
+   document including many of the participants in ASRG, IETF, and MAAWG
+   activities, and all of the members of the abuse-feedback-report
+   public mailing list.
+
+Appendix B.  Sample Feedback Reports
+
+   This section presents some examples of the use of this message format
+   to report feedback about an arriving message.
+
+B.1.  Simple Report for Email Abuse without Optional Headers
+
+   Simple report:
+
+   From: <abusedesk@example.com>
+   Date: Thu, 8 Mar 2005 17:40:36 EDT
+   Subject: FW: Earn money
+   To: <abuse@example.net>
+   MIME-Version: 1.0
+   Content-Type: multipart/report; report-type=feedback-report;
+        boundary="part1_13d.2e68ed54_boundary"
+
+   --part1_13d.2e68ed54_boundary
+   Content-Type: text/plain; charset="US-ASCII"
+   Content-Transfer-Encoding: 7bit
+
+   This is an email abuse report for an email message received from IP
+   192.0.2.1 on Thu, 8 Mar 2005 14:00:00 EDT.  For more information
+   about this format please see http://www.mipassoc.org/arf/.
+
+   --part1_13d.2e68ed54_boundary
+   Content-Type: message/feedback-report
+
+   Feedback-Type: abuse
+   User-Agent: SomeGenerator/1.0
+   Version: 1
+
+   --part1_13d.2e68ed54_boundary
+   Content-Type: message/rfc822
+   Content-Disposition: inline
+
+   Received: from mailserver.example.net
+        (mailserver.example.net [192.0.2.1])
+        by example.com with ESMTP id M63d4137594e46;
+        Thu, 08 Mar 2005 14:00:00 -0400
+
+
+
+Shafranovich, et al.         Standards Track                   [Page 22]
+
+RFC 5965               Format for Feedback Reports           August 2010
+
+
+   From: <somespammer@example.net>
+   To: <Undisclosed Recipients>
+   Subject: Earn money
+   MIME-Version: 1.0
+   Content-type: text/plain
+   Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net
+   Date: Thu, 02 Sep 2004 12:31:03 -0500
+
+   Spam Spam Spam
+   Spam Spam Spam
+   Spam Spam Spam
+   Spam Spam Spam
+   --part1_13d.2e68ed54_boundary--
+
+   Example 1: Required fields only
+
+   Illustration of a feedback report generated according to this
+   specification.  Only the required fields are used.
+
+B.2.  Full Report for Email Abuse with All Headers
+
+   A full email abuse report:
+
+   From: <abusedesk@example.com>
+   Date: Thu, 8 Mar 2005 17:40:36 EDT
+   Subject: FW: Earn money
+   To: <abuse@example.net>
+   MIME-Version: 1.0
+   Content-Type: multipart/report; report-type=feedback-report;
+        boundary="part1_13d.2e68ed54_boundary"
+
+   --part1_13d.2e68ed54_boundary
+   Content-Type: text/plain; charset="US-ASCII"
+   Content-Transfer-Encoding: 7bit
+
+   This is an email abuse report for an email message received from IP
+   192.0.2.1 on Thu, 8 Mar 2005 14:00:00 EDT.  For more information
+   about this format please see http://www.mipassoc.org/arf/.
+
+   --part1_13d.2e68ed54_boundary
+   Content-Type: message/feedback-report
+
+   Feedback-Type: abuse
+   User-Agent: SomeGenerator/1.0
+   Version: 1
+   Original-Mail-From: <somespammer@example.net>
+   Original-Rcpt-To: <user@example.com>
+   Arrival-Date: Thu, 8 Mar 2005 14:00:00 EDT
+
+
+
+Shafranovich, et al.         Standards Track                   [Page 23]
+
+RFC 5965               Format for Feedback Reports           August 2010
+
+
+   Reporting-MTA: dns; mail.example.com
+   Source-IP: 192.0.2.1
+   Authentication-Results: mail.example.com;
+                  spf=fail smtp.mail=somespammer@example.com
+   Reported-Domain: example.net
+   Reported-Uri: http://example.net/earn_money.html
+   Reported-Uri: mailto:user@example.com
+   Removal-Recipient: user@example.com
+
+   --part1_13d.2e68ed54_boundary
+   Content-Type: message/rfc822
+   Content-Disposition: inline
+
+   From: <somespammer@example.net>
+   Received: from mailserver.example.net (mailserver.example.net
+        [192.0.2.1]) by example.com with ESMTP id M63d4137594e46;
+        Thu, 08 Mar 2005 14:00:00 -0400
+
+   To: <Undisclosed Recipients>
+   Subject: Earn money
+   MIME-Version: 1.0
+   Content-type: text/plain
+   Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net
+   Date: Thu, 02 Sep 2004 12:31:03 -0500
+
+   Spam Spam Spam
+   Spam Spam Spam
+   Spam Spam Spam
+   Spam Spam Spam
+   --part1_13d.2e68ed54_boundary--
+
+   Example 1: Generic abuse report with maximum returned information
+
+   A contrived example in which the report generator has returned all
+   possible information about an abuse incident.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Shafranovich, et al.         Standards Track                   [Page 24]
+
+RFC 5965               Format for Feedback Reports           August 2010
+
+
+Authors' Addresses
+
+   Yakov Shafranovich
+   ShafTek Enterprises
+   4014 Labyrinth Rd.
+   Baltimore, MD  21215
+   US
+
+   EMail: ietf@shaftek.org
+   URI:   http://www.shaftek.org
+
+
+   John R. Levine
+   Taughannock Networks
+   PO Box 727
+   Trumansburg, NY  14886
+   US
+
+   Phone: +1 831 480 2300
+   EMail: standards@taugh.com
+
+
+   Murray S. Kucherawy
+   Cloudmark
+   128 King St., 2nd Floor
+   San Francisco, CA  94107
+   US
+
+   Phone: +1 415 946 3800
+   EMail: msk@cloudmark.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Shafranovich, et al.         Standards Track                   [Page 25]
+