| TOC |
|
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 © The Internet Society (2005).
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.
1.
Introduction
2.
Intent
3.
Requirements
4.
Format of Email Feedback Reports
5.
Format of 'message/feedback-report' Content Type
5.1.
Required Fields
5.2.
Optional Fields Appearing Once
5.3.
Optional Fields Appearing Multiple Times
6.
MIME Type Registration of message/feedback-report
7.
Extensibility
8.
IANA Considerations
8.1.
Initial Values for the Header Names Registry
8.2.
Initial values for the "Feedback-Type" registry
9.
Security Considerations
10.
Acknowledgments
11.
References
11.1.
Normative References
11.2.
Informative References
Appendix A.
Appendix A - Sample Feedback Reports
A.1.
Simple Report for Email Abuse without Optional Headers
A.2.
Opt-Out Report without Message Body
A.3.
Full Report for Email Abuse with All Headers
Appendix B.
Status of This Document [To Be Removed Upon Publication]
B.1.
Discussion Venue
B.2.
Document Repository and Public Website
B.3.
Document History
B.4.
Outstanding Issues
§
Author's Address
§
Intellectual Property and Copyright Statements
| TOC |
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 (Freed, N., Klensin, J., and J. Postel, “Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures,” November 1996.) [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 (Vaudreuil, G., “The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages,” January 2003.) [1]. While there have been previous work in this area([12] (Crissman, G., “Proposed Spam Reporting BCP Document,” May 2005.) and [13] (Anti-Spam Research Group (ASRG) of the Internet Research Task Force (IRTF), “Abuse Reporting Standards Subgroup of the ASRG,” May 2005.)), 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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [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.
| TOC |
The reports defined in this document are intended for several purposes:
Please note that while the parent "multipart/report" content type defined in RFC 3462 (Vaudreuil, G., “The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages,” January 2003.) [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.
| TOC |
The following requirements are necessary for feedback reports (the actual standard is defined in the next sections) :
| TOC |
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 (Vaudreuil, G., “The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages,” January 2003.) [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 (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” November 1996.) [3]) OR a copy of the headers from the original message with MIME content type of "text/rfc822-headers" (as defined in RFC 3462 (Vaudreuil, G., “The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages,” January 2003.) [1]). This part MUST BE included (unlike RFC 3462 (Vaudreuil, G., “The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages,” January 2003.) [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).
| TOC |
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 (Crocker, D., “Standard for the format of ARPA Internet text messages,” August 1982.) [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.
| TOC |
The following header fields are REQUIRED and MUST only appear once:
| TOC |
The following header fields are OPTIONAL and MUST NOT appear more than once:
| TOC |
The following set of header fields are OPTIONAL and MAY appear more than once:
| TOC |
This section provides the media type registration application (as per RFC 2048 (Freed, N., Klensin, J., and J. Postel, “Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures,” November 1996.) [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:
Yakov Shafranovich <ietf@shaftek.org>
Intended usage: COMMON
Author/Change controller: IESG
| TOC |
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.
| TOC |
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 (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” October 1998.) [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:
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:
| TOC |
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
| TOC |
The initial names and descriptions are provided below. The RFC number used for registration of these values is this document.
| TOC |
See section 3 of RFC 3462 (Vaudreuil, G., “The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages,” January 2003.) [1]
| TOC |
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.
| TOC |
| TOC |
| TOC |
| [11] | Freed, N., Klensin, J., and J. Postel, “Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures,” BCP 13, RFC 2048, November 1996 (TXT, HTML, XML). |
| [12] | Crissman, G., “Proposed Spam Reporting BCP Document,” May 2005 (HTML). |
| [13] | Anti-Spam Research Group (ASRG) of the Internet Research Task Force (IRTF), “Abuse Reporting Standards Subgroup of the ASRG,” May 2005 (HTML). |
| [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 (TXT, HTML, XML). |
| TOC |
| TOC |
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--
| TOC |
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--
| TOC |
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--
| TOC |
| TOC |
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).
| TOC |
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/.
| TOC |
Changes from draft-shafranovich-feedback-report-01-pre1 to draft-shafranovich-feedback-report-01:
Changes from draft-shafranovich-feedback-report-00 to draft-shafranovich-feedback-report-01-pre1:
Changes from draft-shafranovich-abuse-report-00 to draft-shafranovich-feedback-report-00:
| TOC |
Here is a list of some outstanding issues for this document that have not been finalized:
| TOC |
| Yakov Shafranovich | |
| SolidMatrix Technologies, Inc. | |
| Email: | ietf@shaftek.org |
| URI: | http://www.shaftek.org |
| TOC |
Copyright © 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.
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.
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.
Funding for the RFC Editor function is currently provided by the Internet Society.