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. 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. NOTE: This document may be incomplete and is intented to evolve based on public discussion and feedback

The reports defined in this document are intended for several purposes: To inform ISPs about email abuse originating from their networks To provide feedback to email service providers about abuse complaints To inform the author of the message that the receiver wants to opt out. Note that the reports defined in this document are limited to providing feedback about email only.

The following requirements are necessary for feedback reports : They must be both human and machine readable Copy of the original email message or email headers must be enclosed in order to allow the receiver to properly handle the report.

An email feedback report is 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 The second MIME part of the message contains a machine readable abuse report with the content type of "message/feedback-report" (defined later on in this document). 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). Each abuse report should related to a single originating message. The subject line of the abuse report should read as "Email Feedback 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. If email authentication is used, the sender may substitute the text "for domain YYYYY.ZZZZ" where "YYYYY.ZZZZ" is the authenticated domain. It is preferable that all original email headers are included even though they are defined as optional in RFC 3462.

The message/feedback-report content type consists of several header fields as follows: "Source-IP:" - contains an IPv4 or IPv6 address of the MTA from which the original message was received. "Received-Date:" - date the original message was received. This field is formatted in according to the definition in section 3.3 of RFC 2822 "Original-Message-ID:" - contains the RFC 2822 Message-ID of the original message "Feedback-Type:" - contains the type of feedback as defined in the corresponding IANA registry. "Authenticated-Domain:" and "Authenticated-Domain-Method:" - defines the authenticated domain and method used for perform that authentication. The list of method tokens is contained in the corresponding IANA registry. Note that the actual type of authentication used is outside the scope of this document.

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 section 3 of RFC 3462 Interoperability considerations: none 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

After IESG approval, IANA is expected to register MIME type "message/feedback-report" using the application provided in this document and setup two registries for "Feedback-Type" and "Authentication-Domain-Method" headers. Below are the initial values for these registries. Initial values for the "Feedback-Type" registry: abuse - spam or some other kind of email abuse opt-out - a request to opt out from a mailing list. virus - report of a virus found in the originating message Initial values for the "Authentication-Domain-Method" registry: domainkeys - as defined in delany-domainkeys-base iim - as defined in fenton-identified-mail sender-id - as defined in lyon-senderid-core spf - as defined in schlitt-spf-classic

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.

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. E-mail on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction in what a sending host can use as the reverse-path of a message. This document describes a protocol whereby a domain can explicitly authorize the hosts that are allowed to use its domain name in a reverse-path, and a way for receiving hosts to check such authorization. "DomainKeys" creates a domain-level authentication framework for email by using public-key technology and the DNS to prove the provenance and contents of an email. This document defines the base framework of digitally signing email on a per-domain basis. Subsequent documents leverage this base framework to prove and validate email delivery paths as well as extend signing to facilitate per-user authentication. The ultimate goal of this framework is to unequivocally prove and protect identity while retaining the semantics of Internet email as it is known today. Proof and protection of email identity may assist in the global control of "spam" and "phishing". While this document presents technical details, it is not yet intended as a definitive or final specification, rather, the intent is to define a framework and sufficient technical detail to promote experimental deployment with a view to evolving into a comprehensive authentication standard for email. Internet mail suffers from the fact that much unwanted mail is sent using spoofed addresses -- "spoofed" in this case means the address is used without the permission of the domain owner. This document describes a family of tests by which SMTP servers can determine whether an e-mail address in a received message was used with the permission of the owner of the domain contained in that e-mail address. This document describes extensions to the format of electronic mail messages and a public-key infrastructure to permit verification of the source of messages by either mail transport agents (MTAs) or mail user agents (MUAs). This may be used to implement a policy which, for example, favors the delivery of identified messages over messages lacking signatures or having incorrect signatures. Mechanisms by which signing of messages and verification of signatures can be performed by a trusted MTA, in order to minimize impact on the user, are also presented. 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.

From: <abusedesk@example.com> Date: Thu, 8 Mar 2005 17:40:36 EDT Subject: Email Abuse Report for IP 10.67.41.167 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. --part1_13d.2e68ed54_boundary Content-Type: message/feedback-report Source-IP: 10.67.41.167 Received-Date: Thu, 8 Mar 2005 14:00:00 EDT Original-Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net Feedback-Type: abuse --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--

Comments about this document should be sent directly to the author at via .

Copies of this and earlier versions including multiple formats can be found at .

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.