SolidMatrix Technologies, Inc.

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

spam abuse 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.

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. 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. While there have been previous work in this area( and ), 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. 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.

The reports defined in this document are intended for several purposes: To inform ISPs about email abuse originating from or related to their networks To provide feedback about abuse complaints to email service providers and relevant third parties (such as reputation providers) To inform email service provides about opt-out requests Please note that while the parent "multipart/report" content type defined in RFC 3462 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.

The following requirements are necessary for feedback reports (the actual standard is defined in the next sections) : They must be both human and machine readable 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. The machine readable section must provide ability for the report generators to share metadata with receivers, The format must be extensible.

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). The following apply: The "report-type" parameter of "multipart/report" type is set to "feedback-report" The first MIME part of the message contains a human readable description of the report and MUST be included. 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. 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) OR a copy of the headers from the original message with MIME content type of "text/rfc822-headers" (as defined in RFC 3462). This part MUST BE included (unlike RFC 3462). 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. Each feedback report MUST be related to only a SINGLE email message. Summary and aggregate formats are outside the scope of this specification. 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).

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

The following header fields are REQUIRED and MUST only appear once: "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. "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. "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 "0.1".

The following header fields are OPTIONAL and MUST NOT appear more than once: "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. "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. "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. "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.

The following set of header fields are OPTIONAL and MAY appear more than once: "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. Report receivers should note that this field only indicates an assertion made by the report generator. "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. "Reported-URI:" - indicates a URI that the report generator believes to be relevant to the report. URI format is defined in RFC 2396. "Removal-Recipient:" - indicates the email address to be removed from the mailing list (MUST only be used with "opt-out" and "opt-out-list" types). The format of this field is defined in section 3.4.1 of RFC 2822.

This section provides the media type registration application (as per RFC 2048, 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: Yakov Shafranovich <ietf@shaftek.org> Intended usage: COMMON Author/Change controller: IESG

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.

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 (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: Name of the field being registered Short description of the field Whether the field can appear more than once Which "Feedback-Type" types does this field apply to (or "any") 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: Name of the feedback type being registered Short description The RFC number (or Internet draft name) in which this feedback type is registered

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

The initial names and descriptions are provided below. The RFC number used for registration of these values is this document. abuse - spam or some other kind of email abuse fraud - indicates some kind of fraud or phishing activity. opt-out - a request to opt out from ALL mailing lists from this provider. opt-out-list - a request to opt out from THIS mailing list ONLY. other - any other feedback that doesn't fit into other types. virus - report of a virus found in the originating message

See section 3 of RFC 3462

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.

USC/ISI

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

IBM Corporation

3039 Cornwallis Ave. PO Box 12195 - BRQA/502 Research Triangle Park NC 27709-2195 919-254-7798 narten@raleigh.ibm.com

Maxware

Pirsenteret N-7005 Trondheim Norway +47 73 54 57 97 Harald@Alvestrand.no

General Internet Assigned Numbers Authority IANA Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication algorithm for IPSec). To insure that such quantities have consistent values and interpretations in different implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA). In order for the IANA to manage a given name space prudently, it needs guidelines describing the conditions under which new values can be assigned. If the IANA is expected to play a role in the management of a name space, the IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a name space and provides guidelines to document authors on the specific text that must be included in documents that place demands on the IANA. Department of Information and Computer Science

University of California, Irvine Irvine CA 92697-3425 +1(949)824-1715 fielding@ics.uci.edu

World Wide Web Consortium

MIT Laboratory for Computer Science, NE43-356 545 Technology Square Cambridge MA 02139 +1(617)258-8682 jg@w3.org

Compaq Computer Corporation

Western Research Laboratory 250 University Avenue Palo Alto CA 94305 mogul@wrl.dec.com

World Wide Web Consortium

MIT Laboratory for Computer Science, NE43-356 545 Technology Square Cambridge MA 02139 +1(617)258-8682 frystyk@w3.org

Xerox Corporation

MIT Laboratory for Computer Science, NE43-356 3333 Coyote Hill Road Palo Alto CA 94034 masinter@parc.xerox.com

Microsoft Corporation

1 Microsoft Way Redmond WA 98052 paulle@microsoft.com

World Wide Web Consortium

MIT Laboratory for Computer Science, NE43-356 545 Technology Square Cambridge MA 02139 +1(617)258-8682 timbl@w3.org

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers . A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068 . This memo defines a new message header for use with [MAIL] messages to indicate the results of sender authentication efforts to mail user agents (MUAs) in order to equip them to relay that information in a convenient way to users. Innosoft International, Inc.

1050 East Garvey Avenue South West Covina CA 91790 US +1 818 919 3600 +1 818 919 3614 ned@innosoft.com

First Virtual Holdings

25 Washington Avenue Morristown NJ 07960 US +1 201 540 8967 +1 201 993 3032 nsb@nsb.fv.com

STD 11, RFC 822 defines a message representation protocol specifying considerable detail about US-ASCII message headers, but which leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for (1) textual message bodies in character sets other than US-ASCII, (2) an extensible set of different formats for non-textual message bodies, (3) multi-part message bodies, and (4) textual header information in character sets other than US-ASCII. These documents are based on earlier work documented in RFC 934, STD 11 and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822. The initial document in this set, RFC 2045, specifies the various headers used to describe the structure of MIME messages. This second document defines the general structure of the MIME media typing sytem and defines an initial set of media types. The third document, RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. The fourth document, RFC 2048, specifies various IANA registration procedures for MIME-related facilities. The fifth and final document, RFC 2049, describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography. These documents are revisions of RFCs 1521 and 1522, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions. Nokia

232 Java Drive Sunnyvale CA 94089 USA +1 408 990-2004 +1 408 743-5677 hinden@iprg.nokia.com

Cisco Systems, Inc.

170 West Tasman Drive San Jose CA 95134-1706 USA +1 408 527-8213 +1 408 527-8254 deering@cisco.com

Internet internet protocol version 6 IPv6 addressing multicast This specification defines the addressing architecture of the IP Version 6 protocol . The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their 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. Note that the force of these words is modified by the requirement level of the document in which they are used. World Wide Web Consortium

MIT Laboratory for Computer Science, NE43-356 545 Technology Square Cambridge MA 02139 +1(617)258-8682 timbl@w3.org

Department of Information and Computer Science

University of California, Irvine Irvine CA 92697-3425 +1(949)824-1715 fielding@ics.uci.edu

Xerox PARC

3333 Coyote Hill Road Palo Alto CA 94034 +1(415)812-4333 masinter@parc.xerox.com

Applications uniform resource URI A Uniform Resource Identifier (URI) is a compact string of characters for identifying an abstract or physical resource. This document defines the generic syntax of URI, including both absolute and relative forms, and guidelines for their use; it revises and replaces the generic definitions in RFC 1738 and RFC 1808. This document defines a grammar that is a superset of all valid URI, such that an implementation can parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier type. This document does not define a generative grammar for URI; that task will be performed by the individual specifications of each URI scheme. This paper describes a "superset" of operations that can be applied to URI. It consists of both a grammar and a description of basic functionality for URI. To understand what is a valid URI, both the grammar and the associated description have to be studied. Some of the functionality described is not applicable to all URI schemes, and some operations are only possible when certain media types are retrieved using the URI, regardless of the scheme used. University of Delaware, Dept. of Electrical Engineering

Newark DE 19711 US DCrocker@UDel-Relay

Innosoft International, Inc.

1050 East Garvey Avenue South West Covina CA 91790 USA +1 818 919 3600 +1 818 919 3614 ned@innosoft.com

MCI

2100 Reston Parkway Reston VA 22091 +1 703 715-7361 +1 703 715-7436 klensin@mci.net

USC/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90292 USA +1 310 822 1511 +1 310 823 6714 Postel@ISI.EDU

Applications mail media type multipurpose internet mail extensions STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for (1) textual message bodies in character sets other than US-ASCII, (2) an extensible set of different formats for non-textual message bodies, (3) multi-part message bodies, and (4) textual header information in character sets other than US-ASCII. These documents are based on earlier work documented in RFC 934, STD 11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822. This fourth document, RFC 2048, specifies various IANA registration procedures for the following MIME facilities: (1) media types, (2) external body access types, (3) content-transfer-encodings. Registration of character sets for use in MIME is covered elsewhere and is no longer addressed by this document. These documents are revisions of RFCs 1521 and 1522, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions. news.admin.net-abuse.email

strads@excite.com http://www.tmisnet.com/~strads/

Anti-Spam Research Group (ASRG) of the Internet Research Task Force (IRTF)

http://asrg.sp.am

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

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

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

Discussion about this document should be directed to the ABUSE-FEEDBACK-REPORT mailing list which is also reachable via . Of course, comments directly to the author are always welcome (you can send them via email to ).

Copies of this and earlier versions including multiple formats can be found at . A public website regarding this draft and related efforts is located at .

Changes from draft-shafranovich-feedback-report-01-pre1 to draft-shafranovich-feedback-report-01: Added an "Outstanding Issues" section. Minor spelling mistakes and clarifications. Added links to previous work and more examples. 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: Changed the introduction section to clarify specific points that are out of scope for this document Added pointers to a public mailing list for discussion and public web page Clarified the intent section and added some extra points to it Added a reference to RFC 2119 and changed the document to comply Made it clear that the requirements section) is not the one defining the standard Clarified the main format section to make all three parts mandatory 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 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. 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". Example has been updated to reflect new headers. 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: Name of the format and report changed to 'feedback-report' Minor spelling corrections Added authentication headers and registry Added feedback-type header and registry.

Here is a list of some outstanding issues for this document that have not been finalized: Whether encoding of the machine readable part should be limited to 7-bit 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. Whether the "from" address should be required to be a human just like other RFCs in the "message/report" family. Whether there is a need for a new header to indicate munging of the included email message. Whether different type of convention should be allowed for subject lines. 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.