[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 draft-ietf-marf-base

Network Working Group                                    Y. Shafranovich
Internet-Draft                            SolidMatrix Technologies, Inc.
Expires: November 14, 2005                                  May 13, 2005


            An Extensible Format for Email Feedback Reports
               draft-shafranovich-feedback-report-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on November 14, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document defines an extensible format and MIME type that may be
   used by network 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.







Shafranovich            Expires November 14, 2005               [Page 1]

Internet-Draft         Format for Feedback Reports              May 2005


Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Intent . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.   Requirements . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.   Format of Email Feedback Reports . . . . . . . . . . . . . .   4
   5.   Format of 'message/feedback-report' Content Type . . . . . .   5
     5.1  Required Fields  . . . . . . . . . . . . . . . . . . . . .   5
     5.2  Optional Fields Appearing Once . . . . . . . . . . . . . .   6
     5.3  Optional Fields Appearing Multiple Times . . . . . . . . .   6
   6.   MIME Type Registration of message/feedback-report  . . . . .   7
   7.   Extensibility  . . . . . . . . . . . . . . . . . . . . . . .   8
   8.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .   8
     8.1  Initial Values for the Header Names Registry . . . . . . .   9
     8.2  Initial values for the "Feedback-Type" registry  . . . . .  10
   9.   Security Considerations  . . . . . . . . . . . . . . . . . .  11
   10.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  11
   11.  References . . . . . . . . . . . . . . . . . . . . . . . . .  11
     11.1   Normative References . . . . . . . . . . . . . . . . . .  11
     11.2   Informative References . . . . . . . . . . . . . . . . .  12
        Author's Address . . . . . . . . . . . . . . . . . . . . . .  12
   A.   Appendix A - Sample Feedback Reports . . . . . . . . . . . .  12
     A.1  Simple Report for Email Abuse without Optional Headers . .  12
     A.2  Opt-Out Report without Message Body  . . . . . . . . . . .  13
     A.3  Full Report for Email Abuse with All Headers . . . . . . .  14
   B.   Status of This Document [To Be Removed Upon Publication] . .  16
     B.1  Discussion Venue . . . . . . . . . . . . . . . . . . . . .  16
     B.2  Document Repository and Public Website . . . . . . . . . .  16
     B.3  Document History . . . . . . . . . . . . . . . . . . . . .  16
     B.4  Outstanding Issues . . . . . . . . . . . . . . . . . . . .  17
        Intellectual Property and Copyright Statements . . . . . . .  19




















Shafranovich            Expires November 14, 2005               [Page 2]

Internet-Draft         Format for Feedback Reports              May 2005


1.  Introduction

   As the spam problem has grown in the past few years, network
   operators have begun to exchange abuse reports among themselves and
   other parties to combat this problem.  However, different operators
   define their own formats and the receivers are forced to write custom
   software to interpret the many types of them.  In addition, many
   operators use various other report formats to provide non-abuse
   feedback about processed email.  This memo seeks to define a standard
   extensible format and the "message/feedback-report" MIME type for
   these reports in accordance with RFC 2048 [11].  This format and
   content type is intended to be used within the scope of the framework
   of the "multipart/report" content type defined in RFC 3462 [1].
   While there have been previous work in this area([12] and [13]), none
   of them have yet been sucessful.  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 feedback
   loops, virus reports and other similar activities.

   This document only defines the format and content type to be used for
   these reports.  Determination of where these reports should be sent,
   how trust among report senders and receivers is established, and
   reports related to more than one message are outside the scope of
   this document.

   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 RFC 2119 [2].

   NOTE: This document may be incomplete and is intented to evolve based
   on public discussion and feedback.  Readers are encourages to submit
   their comments and suggestions.

2.  Intent

   The reports defined in this document are intended for several
   purposes:

   o  To inform ISPs about email abuse originating from or related to
      their networks

   o  To provide feedback about abuse complaints to email service
      providers and relevant third parties (such as reputation
      providers)





Shafranovich            Expires November 14, 2005               [Page 3]

Internet-Draft         Format for Feedback Reports              May 2005


   o  To inform email service provides about opt-out requests

   Please note that while the parent "multipart/report" content type
   defined in RFC 3462 [1] 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.

3.  Requirements

   The following requirements are necessary for feedback reports (the
   actual standard is defined in the next sections) :

   o  They must be both human and machine readable

   o  A copy of the original email message (body and headers) or the
      message headers must be enclosed in order to allow the receiver to
      properly handle the report.

   o  The machine readable section must provide ability for the report
      generators to share metadata with receivers,

   o  The format must be extensible.


4.  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 RFC 3462 [1]).  The following apply:

   a.  The "report-type" parameter of "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.

   c.  The second MIME part of the message is a machine-readable section
       with the content type of "message/feedback-report" (defined later
       on in this document) and MUST be included.  This section is
       intended to convey metadata 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 contains either a full copy of
       the original message with a MIME content type of "message/rfc822"
       (as defined in RFC 2046 [3]) OR a copy of the headers from the
       original message with MIME content type of "text/rfc822-headers"
       (as defined in RFC 3462 [1]).  This part MUST BE included (unlike



Shafranovich            Expires November 14, 2005               [Page 4]

Internet-Draft         Format for Feedback Reports              May 2005


       RFC 3462 [1]).  While some operators may choose to modify or
       munge this portion for privacy or legal reasons, it is
       RECOMMENDED that the entire original email message be included
       without any modification.

   e.  Each feedback report MUST be related to only a SINGLE email
       message.  Summary and aggregate formats are outside the scope of
       this specification.

   f.  The subject line of the feedback report SHOULD be the same as the
       included email message and MAY include only the standard
       forwarding prefix used by MUAs such as "FW:" (many smaller
       operators using MUAs for abuse handling rely on the subject lines
       for processing).


5.  Format of 'message/feedback-report' Content Type

   This content type provides a machine-readable section intended to let
   the report generator convey metadata to the report receiver.  The
   intent of this section is it allow report generators to convey
   metadata to report receivers that may not available or may not be
   readily available from the originating email message or headers.

   The body of this content type consists of multiple "fields" formatted
   according to the ABNF of RFC 822 [14] header "fields".  This section
   defines the initial set of fields provided by this specification.
   Additional fields maybe registered according to the procedure
   described later on in this document.  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 true.

5.1  Required Fields

   The following header fields are REQUIRED and MUST only appear once:

   o  "Feedback-Type:" - contains the type of feedback report (as
      defined in the corresponding IANA registry).  This is intended to
      let report generators 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 RFC 2616 [4].

   o  "Version" - indicates the version of specification that the report
      generator is using to generate the report.  The version number in



Shafranovich            Expires November 14, 2005               [Page 5]

Internet-Draft         Format for Feedback Reports              May 2005


      this specification is set to "0.1".


5.2  Optional Fields Appearing Once

   The following header fields are OPTIONAL and MUST NOT appear more
   than once:

   o  "Original-Mail-From:" - 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.1.2 of RFC 2821 [5].

   o  "Original-Rcpt-To:" - copy of the email address used in the RCPT
      TO portion of the original SMTP transaction.  The format of this
      field is defined in section 4.1.1.3 of RFC 2821 [5].

   o  "Received-Date:" - indicates the date the original message was
      received by the report generator.  This field MUST BE formatted as
      per section 3.3 of RFC 2822 [6].

   o  "Source-IP:" - contains an IPv4 or IPv6 address of the MTA from
      which the original message was received.  IPv4 addresses are to be
      formatted in dot-decimal notation as currently used by the
      community.  IPv6 addresses MUST BE formatted as per section 2.2 of
      RFC 2373 [7].


5.3  Optional Fields Appearing Multiple Times

   The following set of header fields are OPTIONAL and MAY appear more
   than once:

   o  "Authentication-Results:" - indicates the result of an
      authentication check run by the report generator.  The format of
      this field is is defined in draft-kucherawy-sender-auth-header
      [8].  Report receivers should note that this field only indicates
      an assertion made by the report generator.

   o  "Reported-Domain:" - indicates a domain name that the report
      generator believes to be relevant to the report.  Domain format is
      defined in section 2.3.1 of RFC 1035 [9].

   o  "Reported-URI:" - indicates a URI that the report generator
      believes to be relevant to the report.  URI format is defined in
      RFC 2396 [15].

   o  "Removal-Recipient:" - indicates the email address to be removed
      from the mailing list (MUST only be used with  "opt-out" and "opt-



Shafranovich            Expires November 14, 2005               [Page 6]

Internet-Draft         Format for Feedback Reports              May 2005


      out-list" types).  The format of this field is defined in section
      3.4.1 of RFC 2822 [6].


6.  MIME Type Registration of message/feedback-report

   This section provides the media type registration application (as per
   RFC 2048 [11], which will be submitted to IANA after IESG approval of
   this document.

   To: ietf-types@iana.org

   Subject: Registration of MIME media types message/feedback-report

   MIME media type name: message

   MIME 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.

   Security considerations:

      See the "Security Considerations" of this document.

   Interoperability considerations: implementors MUST ignore any fields
   they do not support

   Published specification: this document

   Applications which use this media type: Abuse helpdesk software for
   ISPs

   Additional information:

      Magic number(s): none

      File extension(s): none

      Macintosh File Type Code(s): none

   Person and email address to contact for further information:



Shafranovich            Expires November 14, 2005               [Page 7]

Internet-Draft         Format for Feedback Reports              May 2005


      Yakov Shafranovich <ietf@shaftek.org>

   Intended usage: COMMON

   Author/Change controller: IESG

7.  Extensibility

   Like many other formats and protocols, this format may need to be
   extended overtime to fit the ever changing landscape of the Internet.
   Therefore, extensibility is being provided via two IANA registries:
   one for feedback types and a second for header fields.  The feedback
   type registry is to be used in conjunction with the "Feedback-Type"
   field above.  The header name registry is intended for registration
   of new metadata 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
   can only registered 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 SHOULD ignore any fields they do not support.

8.  IANA Considerations

   After IESG approval, IANA is expected to register MIME type "message/
   feedback-report" using the application provided in this document and
   setup two registries: one for header field names and a second for
   "Feedback-Type" values.  This section contains the templates used for
   registration of new entries in these registries and initial values.
   New registrations to these two registries MUST have approval by an
   Designated Expert in accordance with the Expert Review guidelines as
   described in RFC 2434 [10] (the expert should be appointed by the
   Area Directors of the Applications Area).  Any new field registered
   is considered OPTIONAL unless a new version of this specification is
   published.

   For the header name registry, the following MUST be provided in an
   RFC publication (or Internet draft with IETF consensus or IESG
   approval) in order to register a new header field name:

   1.  Name of the field being registered

   2.  Short description of the field

   3.  Whether the field can appear more than once




Shafranovich            Expires November 14, 2005               [Page 8]

Internet-Draft         Format for Feedback Reports              May 2005


   4.  Which "Feedback-Type" types does this field apply to (or "any")

   5.  The RFC number (or Internet draft name) in which this header is
       registered

   If the header field being registered requires its own IANA registry,
   than the appropriate registry MUST be properly defined.

   For the feedback type registry, the following MUST be provided in an
   RFC publication (or Internet draft with IETF consensus or IESG
   approval) in order to register a new header field name:

   1.  Name of the feedback type being registered

   2.  Short description

   3.  The RFC number (or Internet draft name) in which this feedback
       type is registered


8.1  Initial Values for the Header Names Registry

   The data below is populated from this document.  The RFC number used
   for registration of these values is this document.

   Field Name: Authentication-Results
   Description: results of authentication check
   Multiple Appearances: Yes
   Related "Feedback-Type": any

   Field Name: Feedback-Type
   Description: type of feedback report
   Multiple Appearances: No
   Related "Feedback-Type": N/A

   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

   Field Name: Original-Rcpt-To
   Description: copy of the email address used in the RCPT TO portion of
   the original SMTP transaction
   Multiple Appearances: No
   Related "Feedback-Type": any

   Field Name: Received-Date



Shafranovich            Expires November 14, 2005               [Page 9]

Internet-Draft         Format for Feedback Reports              May 2005


    Description: date the original message was received
   Multiple Appearances: No
   Related "Feedback-Type": any

   Field Name: Reported-Domain
   Description: relevant domain name
   Multiple Appearances: Yes
   Related "Feedback-Type": any

   Field Name: Reported-URI
   Description: relevant URI
   Multiple Appearances: Yes
   Related "Feedback-Type": any

   Field Name: Removal-Recipient
   Description: email address to be removed from the mailing list
   Multiple Appearances: Yes
   Related "Feedback-Type": opt-out, opt-out-list

   Field Name: Source-IP
   Description: IPv4 or IPv6 address from which the original message was
   received
   Multiple Appearances: No
   Related "Feedback-Type": any

   Field Name: User-Agent
   Description: name and version of the program used
   Multiple Appearances: No
   Related "Feedback-Type": any

   Field Name: Version
   Description: version of specification used
   Multiple Appearances: No
   Related "Feedback-Type": any

8.2  Initial values for the "Feedback-Type" registry

   The initial names and descriptions are provided below.  The RFC
   number used for registration of these values is this document.

   o  abuse - spam or some other kind of email abuse

   o  fraud - indicates some kind of fraud or phishing activity.

   o  opt-out - a request to opt out from ALL mailing lists from this
      provider.





Shafranovich            Expires November 14, 2005              [Page 10]

Internet-Draft         Format for Feedback Reports              May 2005


   o  opt-out-list - a request to opt out from THIS mailing list ONLY.

   o  other - any other feedback that doesn't fit into other types.

   o  virus - report of a virus found in the originating message


9.  Security Considerations

   See section 3 of RFC 3462 [1]

10.  Acknowledgments

   The author 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.

11.  References

11.1  Normative References

   [1]   Vaudreuil, G., "The Multipart/Report Content Type for the
         Reporting of Mail System Administrative Messages", RFC 3462,
         January 2003.

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

   [3]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
         Extensions (MIME) Part Two: Media Types", RFC 2046,
         November 1996.

   [4]   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.

   [5]   Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
         April 2001.

   [6]   Resnick, P., "Internet Message Format", RFC 2822, April 2001.

   [7]   Hinden, R. and S. Deering, "IP Version 6 Addressing
         Architecture", RFC 2373, July 1998.

   [8]   Kucherawy, M., "Message Header for Indicating Sender
         Authentication Status", draft-kucherawy-sender-auth-header-02



Shafranovich            Expires November 14, 2005              [Page 11]

Internet-Draft         Format for Feedback Reports              May 2005


         (work in progress), May 2005.

   [9]   Mockapetris, P., "Domain names - implementation and
         specification", STD 13, RFC 1035, November 1987.

   [10]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, RFC 2434,
         October 1998.

11.2  Informative References

   [11]  Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
         Mail Extensions (MIME) Part Four: Registration Procedures",
         BCP 13, RFC 2048, November 1996.

   [12]  Crissman, G., "Proposed Spam Reporting BCP Document", May 2005,
         <http://www.tmisnet.com/~strads/spam/bcp.html>.

   [13]  Anti-Spam Research Group (ASRG) of the Internet Research Task
         Force (IRTF), "Abuse Reporting Standards Subgroup of the ASRG",
         May 2005, <http://asrg.sp.am/subgroups/abuse_reports.shtml>.

   [14]  Crocker, D., "Standard for the format of ARPA Internet text
         messages", STD 11, RFC 822, August 1982.

   [15]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
         Resource Identifiers (URI): Generic Syntax", RFC 2396,
         August 1998.


Author's Address

   Yakov Shafranovich
   SolidMatrix Technologies, Inc.

   Email: ietf@shaftek.org
   URI:   http://www.shaftek.org

Appendix A.  Appendix A - Sample Feedback Reports

A.1  Simple Report for Email Abuse without Optional Headers










Shafranovich            Expires November 14, 2005              [Page 12]

Internet-Draft         Format for Feedback Reports              May 2005


   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 10.67.41.167 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: 0.1

   --part1_13d.2e68ed54_boundary
   Content-Type: message/rfc822
   Content-Disposition: inline

   From: <somespammer@example.net>
   Received: from mailserver.example.net (mailserver.example.net [10.67.41.167])
             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--


A.2  Opt-Out Report without Message Body








Shafranovich            Expires November 14, 2005              [Page 13]

Internet-Draft         Format for Feedback Reports              May 2005


   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 opt-out report for an email message received from IP 10.67.41.167 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: opt-out
   User-Agent: SomeGenerator/1.0
   Version: 0.1
   Removal-Recipient: user@example.com

   --part1_13d.2e68ed54_boundary
   Content-Type: message/rfc822-headers
   Content-Disposition: inline

   From: <somespammer@example.net>
   Received: from mailserver.example.net (mailserver.example.net [10.67.41.167])
             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
   --part1_13d.2e68ed54_boundary--


A.3  Full Report for Email Abuse with All Headers


   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"




Shafranovich            Expires November 14, 2005              [Page 14]

Internet-Draft         Format for Feedback Reports              May 2005


   --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 10.67.41.167 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: 0.1
   Original-Mail-From: <somespammer@example.net>
   Original-Rcpt-To: <user@example.com>
   Received-Date: Thu, 8 Mar 2005 14:00:00 EDT
   Source-IP: 10.67.41.167
   Authentication-Results: mail.example.com
                  smtp.mail=somespammer@example.com;
                  spf=fail
   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 [10.67.41.167])
             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--







Shafranovich            Expires November 14, 2005              [Page 15]

Internet-Draft         Format for Feedback Reports              May 2005


Appendix B.  Status of This Document [To Be Removed Upon Publication]

B.1  Discussion Venue

   Discussion about this document should be directed to the ABUSE-
   FEEDBACK-REPORT mailing list
   <http://mipassoc.org/mailman/listinfo/abuse-feedback-report> which is
   also reachable via <mailto:abuse-feedback-report@mipassoc.org>.  Of
   course, comments directly to the author are always welcome (you can
   send them via email to <ietf@shaftek.org>).

B.2  Document Repository and Public Website

   Copies of this and earlier versions including multiple formats can be
   found at <http://www.shaftek.org/publications/drafts/abuse-report/>.
   A public website regarding this draft and related efforts is located
   at <http://mipassoc.org/arf/>.

B.3  Document History

   Changes from draft-shafranovich-feedback-report-01-pre1 to
   draft-shafranovich-feedback-report-01:

   o  Added an "Outstanding Issues" section.

   o  Minor spelling mistakes and clarifications.

   o  Added links to previous work and more examples.

   o  Added three new types: "fraud" for phishing, "opt-out-list" for a
      single list opt out, and "other" as a catch-all.

   Changes from draft-shafranovich-feedback-report-00 to
   draft-shafranovich-feedback-report-01-pre1:

   o  Changed the introduction section to clarify specific points that
      are out of scope for this document

   o  Added pointers to a public mailing list for discussion and public
      web page

   o  Clarified the intent section and added some extra points to it

   o  Added a reference to RFC 2119 and changed the document to comply

   o  Made it clear that the requirements section) is not the one
      defining the standard




Shafranovich            Expires November 14, 2005              [Page 16]

Internet-Draft         Format for Feedback Reports              May 2005


   o  Clarified the main format section to make all three parts
      mandatory

   o  Changed section 4f regarding subject lines to mandate that subject
      lines should be left intact.  Removed the convention for subject
      lines that was defined in the previous version

   o  Added text to the the machine readable section clarifying its
      intent.  Also added RFC 2119 references, reorganized fields,
      indicated whether specific header fields can appear more than once
      and provided references as to how they should be formatted.

   o  Removed "Original-Message-ID", "Authenticated-Domain:" and
      "Authenticated-Domain-Method" from the draft including related
      IANA registries.  Added "Version", "User-Agent", Original-Mail-
      From", "Original-Rcpt-To", "Reported-Uri", "Reported-Domain" and
      "Authentication-Results".

   o  Example has been updated to reflect new headers.

   o  Added a new section on extensibility and changed the IANA section
      to reflect that.

   Changes from draft-shafranovich-abuse-report-00 to
   draft-shafranovich-feedback-report-00:

   o  Name of the format and report changed to 'feedback-report'

   o  Minor spelling corrections

   o  Added authentication headers and registry

   o  Added feedback-type header and registry.


B.4  Outstanding Issues

   Here is a list of some outstanding issues for this document that have
   not been finalized:

   o  Whether encoding of the machine readable part should be limited to
      7-bit

   o  Whether there is a need for both "opt-out" and "opt-out-list", and
      whether this format should be used for opt-outs at all.

   o  Whether the "from" address should be required to be a human just
      like other RFCs in the "message/report" family.



Shafranovich            Expires November 14, 2005              [Page 17]

Internet-Draft         Format for Feedback Reports              May 2005


   o  Whether there is a need for a new header to indicate munging of
      the included email message.

   o  Whether different type of convention should be allowed for subject
      lines.

   o  Whether there should be different types defined for "Reported-Uri"
      to better indicate to the report receiver how they are related to
      the email message in question.










































Shafranovich            Expires November 14, 2005              [Page 18]

Internet-Draft         Format for Feedback Reports              May 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Shafranovich            Expires November 14, 2005              [Page 19]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/