.\" automatically generated by xml2rfc v1.28 on 2005-03-30T02:23:20Z .\" .pl 10.0i .po 0 .ll 7.2i .lt 7.2i .nr LL 7.2i .nr LT 7.2i .ds LF Shafranovich .ds RF FORMFEED[Page %] .ds CF Expires September 30, 2005 .ds LH Internet-Draft .ds RH March 2005 .ds CH An Extensible Format for Email Abuse Reports .hy 0 .nh .ad l .nf Network Working Group Y. Shafranovich \%Internet-Draft SolidMatrix Technologies, Inc. Expires: September 30, 2005 March 29, 2005 .ce An Extensible Format for Email Abuse Reports .ce \%draft-shafranovich-abuse-report-00.txt .in 3 .ti 0 Status of this Memo .fi This document is an \%Internet-Draft and is subject to all provisions of Section\03 of RFC\03667. 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 become aware will be disclosed, in accordance with RFC\03668. \%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 September 30, 2005. .ti 0 Copyright Notice Copyright (C) The Internet Society (2005). .ti 0 Abstract This document defines an extensible format and MIME type that may be used by network operators to report email abuse to other parties. This format is intended as a machine readable replacement for various existing abuse report formats currently used in Internet email. .bp .in 0 Table of Contents .nf 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Intent . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Format of Email Abuse Reports . . . . . . . . . . . . . . . . 3 5. Format of \%\'message/abuse-report\' Content Type . . . . . . . . 4 6. MIME Type Registration of \%message/abuse-report . . . . . . . . 4 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 9.1 Normative References . . . . . . . . . . . . . . . . . . . 6 9.2 Informative References . . . . . . . . . . . . . . . . . . 6 Author\'s Address . . . . . . . . . . . . . . . . . . . . . . . 6 A. Appendix A \%- An Sample Abuse Report . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . 8 .bp .fi .in 4 .ti 0 1. Introduction .in 3 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. This memo seeks to define a standard extensible format and the \%"message/abuse-report" MIME type for abuse reports in accordance with RFC 2048 [4]. 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]. This document only defines the format and content type to be used for these reports. Determination of where these reports should be sent is outside the scope of this document. .in 4 .ti 0 2. Intent .in 3 The abuse reports defined in this document are intended for several purposes: .in 7 .ti 3 a. To inform ISPs about email abuse originating from their networks .ti 3 b. To provide feedback to email service providers about abuse complaints .in 3 Note that the abuse reports defined in this document are limited to reporting email abuse only. .in 4 .ti 0 3. Requirements .in 3 The following requirements are necessary for abuse reports : .in 7 .ti 3 a. They must be both human and machine readable .ti 3 b. Copy of the original email message or email headers must be enclosed in order to allow the receiver to properly handle the report. .in 3 .in 4 .ti 0 4. Format of Email Abuse Reports .in 3 An email abuse report is a MIME message with a top level MIME content type of "multipart/report" (as defined in RFC 3462 [1]). The following apply: .in 7 .ti 3 a. The \%"report-type" parameter of "multipart/report" type is set to .bp \%"abuse-report". .ti 3 b. The first MIME part of the message contains a human readable description of the report .ti 3 c. The second MIME part of the message contains a machine readable abuse report with the content type of \%"message/abuse-report" (defined later on in this document). .ti 3 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 [1]) OR a copy of the headers from the original message with MIME content type of \%"text/rfc822-headers" (as defined in RFC 3462 [1]). .ti 3 e. Each abuse report should related to a single originating message. .ti 3 f. The subject line of the abuse report should read as "Email Abuse Report for IP X.X.X.X" where "X.X.X.X" is the source IP of the MTA from which the original message was received. .ti 3 g. Note that unlike the definition in RFC 3462 [1], all three parts are required for abuse reports. .in 3 .in 4 .ti 0 5. Format of \%\'message/abuse-report\' Content Type .in 3 The \%message/abuse-report content type consists of several header fields as follows: .in 7 .ti 3 a. \%"Source-IP:" \%- contains an IPv4 or IPv6 address of the MTA from which the original message was received. .ti 3 b. \%"Received-Date:" \%- date the original message was received. This field is formatted in according to the definition in section 3.3 of RFC 2822 [2] .ti 3 c. \%"Original-Message-ID:" \%- contains the RFC 2822 [2] \%Message-ID of the original message .in 3 .in 4 .ti 0 6. MIME Type Registration of \%message/abuse-report .in 3 This section provides the media type registration application (as per RFC 2048 [4], which will be submitted to IANA after IESG approval of this document. To: \%ietf-types@iana.org .bp Subject: Registration of MIME media types \%message/abuse-report MIME media type name: message MIME subtype name: \%abuse-report Required parameters: none Optional parameters: none Encoding considerations: .in 6 .ti 6 "7bit" encoding is sufficient and MUST be used to maintain readability when viewed by \%non-MIME mail readers. .in 3 Security considerations: .in 6 .ti 6 See section 3 of RFC 3462 [1] .in 3 Interoperability considerations: none Published specification: this document Applications which use this media type: Abuse helpdesk software for ISPs Additional information: .in 6 .ti 6 Magic number(s): none .ti 6 File extension(s): none .ti 6 Macintosh File Type Code(s): none .in 3 Person & email address to contact for further information: .in 6 .ti 6 Yakov Shafranovich .in 3 Intended usage: COMMON Author/Change controller: IESG .in 4 .ti 0 7. IANA Considerations .in 3 After IESG approval, IANA is expected to register MIME type "message/ \%abuse-report" using the application provided in this document. .bp .in 4 .ti 0 8. Security Considerations .in 3 See section 3 of RFC 3462 [1] .in 4 .ti 0 9. References .in 3 .in 5 .ti 0 9.1 Normative References .in 3 .in 8 .ti 3 [1] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC\03462, January 2003. .ti 3 [2] Resnick, P., "Internet Message Format", RFC\02822, April 2001. .ti 3 [3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC\02046, November 1996. .in 5 .ti 0 9.2 Informative References .in 3 .in 8 .ti 3 [4] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP\013, RFC\02048, November 1996. .in 3 .nf .ti 0 Author\'s Address Yakov Shafranovich SolidMatrix Technologies, Inc. Email: ietf@shaftek.org URI: http://www.shaftek.org .fi .in 13 .ti 0 Appendix A. Appendix A \%- An Sample Abuse Report .in 3 .nf From: Date: Thu, 8 Mar 2005 17:40:36 EDT Subject: Email Abuse Report for IP 10.67.41.167 To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=abuse-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. .bp --part1_13d.2e68ed54_boundary Content-Type: message/abuse-report Source-IP: 10.67.41.167 Received-Date: Thu, 8 Mar 2005 14:00:00 EDT Original-Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net --part1_13d.2e68ed54_boundary Content-Type: message/rfc822 Content-Disposition: inline From: 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-- .bp .ti 0 Intellectual Property Statement .fi 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\078 and BCP\079. 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. .ti 0 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. .ti 0 Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP\078, and except as set forth therein, the authors retain all their rights. .ti 0 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.