draft-shafranovich-abuse-report-00.txt		draft-shafranovich-feedback-report-00.txt
	Network Working Group Y. Shafranovich		Network Working Group Y. Shafranovich
	Internet-Draft SolidMatrix Technologies, Inc.		Internet-Draft SolidMatrix Technologies, Inc.
	Expires: September 30, 2005 March 29, 2005		Expires: September 2, 2005 March 2005
	An Extensible Format for Email Abuse Reports		An Extensible Format for Email Feedback Reports
	draft-shafranovich-abuse-report-00.txt		draft-shafranovich-feedback-report-00.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		This document is an Internet-Draft and is subject to all provisions
	of Section 3 of RFC 3667. By submitting this Internet-Draft, each		of Section 3 of RFC 3667. By submitting this Internet-Draft, each
	author represents that any applicable patent or other IPR claims of		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 is aware have been or will be disclosed, and any of
	which he or she become aware will be disclosed, in accordance with		which he or she become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as Internet-
	Internet-Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 30, 2005.		This Internet-Draft will expire on September 2, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	This document defines an extensible format and MIME type that may be		This document defines an extensible format and MIME type that may be
	used by network operators to report email abuse to other parties.		used by network operators to report feedback about received email to
	This format is intended as a machine readable replacement for various		other parties. This format is intended as a machine readable
	existing abuse report formats currently used in Internet email.		replacement for various existing report formats currently used in
			Internet email.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Intent . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Intent . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Format of Email Abuse Reports . . . . . . . . . . . . . . . . 3		4. Format of Email Feedback Reports . . . . . . . . . . . . . . 4
	5. Format of 'message/abuse-report' Content Type . . . . . . . . 4		5. Format of 'message/feedback-report' Content Type . . . . . . 4
	6. MIME Type Registration of message/abuse-report . . . . . . . . 4		6. MIME Type Registration of message/feedback-report . . . . . 5
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 6		8. Security Considerations . . . . . . . . . . . . . . . . . . 6
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 6
	9.1 Normative References . . . . . . . . . . . . . . . . . . . 6		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	9.2 Informative References . . . . . . . . . . . . . . . . . . 6		10.1 Normative References . . . . . . . . . . . . . . . . . . 7
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6		10.2 Informative References . . . . . . . . . . . . . . . . . 7
	A. Appendix A - An Sample Abuse Report . . . . . . . . . . . . . 6		Author's Address . . . . . . . . . . . . . . . . . . . . . . 7
	Intellectual Property and Copyright Statements . . . . . . . . 8		A. Appendix A - An Sample Abuse Report . . . . . . . . . . . . 8
			B. Status of This Document [To Be Removed Upon Publication] . . 9
			B.1 Discussion Venue . . . . . . . . . . . . . . . . . . . . . 9
			B.2 Document Repository . . . . . . . . . . . . . . . . . . . 9
			B.3 Document History . . . . . . . . . . . . . . . . . . . . . 9
			Intellectual Property and Copyright Statements . . . . . . . 10
	1. Introduction		1. Introduction
	As the spam problem has grown in the past few years, network		As the spam problem has grown in the past few years, network
	operators have begun to exchange abuse reports among themselves and		operators have begun to exchange abuse reports among themselves and
	other parties to combat this problem. However, different operators		other parties to combat this problem. However, different operators
	define their own formats and the receivers are forced to write custom		define their own formats and the receivers are forced to write custom
	software to interpret the many types of them. This memo seeks to		software to interpret the many types of them. In addition, many
	define a standard extensible format and the "message/abuse-report"		operators use various other report formats to provide non-abuse
	MIME type for abuse reports in accordance with RFC 2048 [4]. This		feedback about processed email. This memo seeks to define a standard
	format and content type is intended to be used within the scope of		extensible format and the "message/feedback-report" MIME type for
	the framework of the "multipart/report" content type defined in RFC		these reports in accordance with RFC 2048 [4]. This format and
	3462 [1].		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		This document only defines the format and content type to be used for
	these reports. Determination of where these reports should be sent		these reports. Determination of where these reports should be sent
	is outside the scope of this document.		is outside the scope of this document.
			NOTE: This document may be incomplete and is intented to evolve based
			on public discussion and feedback
	2. Intent		2. Intent
	The abuse reports defined in this document are intended for several		The reports defined in this document are intended for several
	purposes:		purposes:
	a. To inform ISPs about email abuse originating from their networks		a. To inform ISPs about email abuse originating from their networks
	b. To provide feedback to email service providers about abuse		b. To provide feedback to email service providers about abuse
	complaints		complaints
	Note that the abuse reports defined in this document are limited to		c. To inform the author of the message that the receiver wants to
	reporting email abuse only.		opt out.
			Note that the reports defined in this document are limited to
			providing feedback about email only.
	3. Requirements		3. Requirements
	The following requirements are necessary for abuse reports :		The following requirements are necessary for feedback reports :
	a. They must be both human and machine readable		a. They must be both human and machine readable
	b. Copy of the original email message or email headers must be		b. Copy of the original email message or email headers must be
	enclosed in order to allow the receiver to properly handle the		enclosed in order to allow the receiver to properly handle the
	report.		report.
	4. Format of Email Abuse Reports		4. Format of Email Feedback Reports
	An email abuse report is a MIME message with a top level MIME content		An email feedback report is a MIME message with a top level MIME
	type of "multipart/report" (as defined in RFC 3462 [1]). The		content type of "multipart/report" (as defined in RFC 3462 [1]). The
	following apply:		following apply:
	a. The "report-type" parameter of "multipart/report" type is set to		a. The "report-type" parameter of "multipart/report" type is set to
	"abuse-report".		"feedback-report".
	b. The first MIME part of the message contains a human readable		b. The first MIME part of the message contains a human readable
	description of the report		description of the report
	c. The second MIME part of the message contains a machine readable		c. The second MIME part of the message contains a machine readable
	abuse report with the content type of "message/abuse-report"		abuse report with the content type of "message/feedback-report"
	(defined later on in this document).		(defined later on in this document).
	d. The third MIME part of the message contains either a full copy of		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"		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		(as defined in RFC 2046 [1]) OR a copy of the headers from the
	original message with MIME content type of "text/rfc822-headers"		original message with MIME content type of "text/rfc822-headers"
	(as defined in RFC 3462 [1]).		(as defined in RFC 3462 [1]).
	e. Each abuse report should related to a single originating message.		e. Each abuse report should related to a single originating message.
	f. The subject line of the abuse report should read as "Email Abuse		f. The subject line of the abuse report should read as "Email
	Report for IP X.X.X.X" where "X.X.X.X" is the source IP of the		Feedback Report for IP X.X.X.X" where "X.X.X.X" is the source IP
	MTA from which the original message was received.		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.
	g. Note that unlike the definition in RFC 3462 [1], all three parts		g. It is preferable that all original email headers are included
	are required for abuse reports.		even though they are defined as optional in RFC 3462 [1].
	5. Format of 'message/abuse-report' Content Type		5. Format of 'message/feedback-report' Content Type
	The message/abuse-report content type consists of several header		The message/feedback-report content type consists of several header
	fields as follows:		fields as follows:
	a. "Source-IP:" - contains an IPv4 or IPv6 address of the MTA from		a. "Source-IP:" - contains an IPv4 or IPv6 address of the MTA from
	which the original message was received.		which the original message was received.
	b. "Received-Date:" - date the original message was received. This		b. "Received-Date:" - date the original message was received. This
	field is formatted in according to the definition in section 3.3		field is formatted in according to the definition in section 3.3
	of RFC 2822 [2]		of RFC 2822 [2]
	c. "Original-Message-ID:" - contains the RFC 2822 [2] Message-ID of		c. "Original-Message-ID:" - contains the RFC 2822 [2] Message-ID of
	the original message		the original message
	6. MIME Type Registration of message/abuse-report		d. "Feedback-Type:" - contains the type of feedback as defined in
			the corresponding IANA registry.
			e. "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.
			6. MIME Type Registration of message/feedback-report
	This section provides the media type registration application (as per		This section provides the media type registration application (as per
	RFC 2048 [4], which will be submitted to IANA after IESG approval of		RFC 2048 [4], which will be submitted to IANA after IESG approval of
	this document.		this document.
	To: ietf-types@iana.org		To: ietf-types@iana.org
	Subject: Registration of MIME media types message/abuse-report
			Subject: Registration of MIME media types message/feedback-report
	MIME media type name: message		MIME media type name: message
	MIME subtype name: abuse-report		MIME subtype name: feedback-report
	Required parameters: none		Required parameters: none
	Optional parameters: none		Optional parameters: none
	Encoding considerations:		Encoding considerations:
	"7bit" encoding is sufficient and MUST be used to maintain		"7bit" encoding is sufficient and MUST be used to maintain
	readability when viewed by non-MIME mail readers.		readability when viewed by non-MIME mail readers.
	skipping to change at page 5, line 38		skipping to change at page 6, line 11
	ISPs		ISPs
	Additional information:		Additional information:
	Magic number(s): none		Magic number(s): none
	File extension(s): none		File extension(s): none
	Macintosh File Type Code(s): none		Macintosh File Type Code(s): none
	Person & email address to contact for further information:		Person and email address to contact for further information:
	Yakov Shafranovich <ietf@shaftek.org>		Yakov Shafranovich <ietf@shaftek.org>
	Intended usage: COMMON		Intended usage: COMMON
	Author/Change controller: IESG		Author/Change controller: IESG
	7. IANA Considerations		7. IANA Considerations
	After IESG approval, IANA is expected to register MIME type		After IESG approval, IANA is expected to register MIME type "message/
	"message/abuse-report" using the application provided in this		feedback-report" using the application provided in this document and
	document.		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 [5]
			iim - as defined in fenton-identified-mail [6]
			sender-id - as defined in lyon-senderid-core [7]
			spf - as defined in schlitt-spf-classic [8]
	8. Security Considerations		8. Security Considerations
	See section 3 of RFC 3462 [1]		See section 3 of RFC 3462 [1]
	9. References		9. Acknowledgments
	9.1 Normative References		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.
			10. References
			10.1 Normative References
	[1] Vaudreuil, G., "The Multipart/Report Content Type for the		[1] Vaudreuil, G., "The Multipart/Report Content Type for the
	Reporting of Mail System Administrative Messages", RFC 3462,		Reporting of Mail System Administrative Messages", RFC 3462,
	January 2003.		January 2003.
	[2] Resnick, P., "Internet Message Format", RFC 2822, April 2001.		[2] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
	[3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part Two: Media Types", RFC 2046, November		Extensions (MIME) Part Two: Media Types", RFC 2046,
	1996.		November 1996.
	9.2 Informative References		10.2 Informative References
	[4] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet		[4] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
	Mail Extensions (MIME) Part Four: Registration Procedures",		Mail Extensions (MIME) Part Four: Registration Procedures",
	BCP 13, RFC 2048, November 1996.		BCP 13, RFC 2048, November 1996.
			[5] Delany, M., "Domain-based Email Authentication Using Public-Keys
			Advertised in the DNS (DomainKeys)",
			draft-delany-domainkeys-base-02 (work in progress), March 2005.
			[6] Fenton, J. and M. Thomas, "Identified Internet Mail",
			draft-fenton-identified-mail-01 (work in progress),
			October 2004.
			[7] Lyon, J., "Sender ID: Authenticating E-Mail",
			draft-lyon-senderid-core-00 (work in progress), November 2004.
			[8] Wong, M., "Sender Policy Framework: Authorizing Use of Domains
			in E-MAIL", draft-schlitt-spf-classic-00 (work in progress),
			January 2005.
	Author's Address		Author's Address
	Yakov Shafranovich		Yakov Shafranovich
	SolidMatrix Technologies, Inc.		SolidMatrix Technologies, Inc.
	Email: ietf@shaftek.org		Email: ietf@shaftek.org
	URI: http://www.shaftek.org		URI: http://www.shaftek.org
	Appendix A. Appendix A - An Sample Abuse Report		Appendix A. Appendix A - An Sample Abuse Report
	From: <abusedesk@example.com>		From: <abusedesk@example.com>
	Date: Thu, 8 Mar 2005 17:40:36 EDT		Date: Thu, 8 Mar 2005 17:40:36 EDT
	Subject: Email Abuse Report for IP 10.67.41.167		Subject: Email Abuse Report for IP 10.67.41.167
	To: <abuse@example.net>		To: <abuse@example.net>
	MIME-Version: 1.0		MIME-Version: 1.0
	Content-Type: multipart/report; report-type=abuse-report; boundary="part1_13d.2e68ed54_boundary"		Content-Type: multipart/report; report-type=feedback-report; boundary="part1_13d.2e68ed54_boundary"
	--part1_13d.2e68ed54_boundary		--part1_13d.2e68ed54_boundary
	Content-Type: text/plain; charset="US-ASCII"		Content-Type: text/plain; charset="US-ASCII"
	Content-Transfer-Encoding: 7bit		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.		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		--part1_13d.2e68ed54_boundary
	Content-Type: message/abuse-report		Content-Type: message/feedback-report
	Source-IP: 10.67.41.167		Source-IP: 10.67.41.167
	Received-Date: Thu, 8 Mar 2005 14:00:00 EDT		Received-Date: Thu, 8 Mar 2005 14:00:00 EDT
	Original-Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net		Original-Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net
			Feedback-Type: abuse
	--part1_13d.2e68ed54_boundary		--part1_13d.2e68ed54_boundary
	Content-Type: message/rfc822		Content-Type: message/rfc822
	Content-Disposition: inline		Content-Disposition: inline
	From: <somespammer@example.netglt;		From: <somespammer@example.net>
	Received: from mailserver.example.net (mailserver.example.net [10.67.41.167])		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		by example.com with ESMTP id M63d4137594e46; Thu, 08 Mar 2005 14:00:00 -0400
	To: <Undisclosed Recipients>		To: <Undisclosed Recipients>
	Subject: Earn money		Subject: Earn money
	MIME-Version: 1.0		MIME-Version: 1.0
	Content-type: text/plain		Content-type: text/plain
	Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net		Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net
	Date: Thu, 02 Sep 2004 12:31:03 -0500		Date: Thu, 02 Sep 2004 12:31:03 -0500
	Spam Spam Spam		Spam Spam Spam
	Spam Spam Spam		Spam Spam Spam
	Spam Spam Spam		Spam Spam Spam
	Spam Spam Spam		Spam Spam Spam
	--part1_13d.2e68ed54_boundary--		--part1_13d.2e68ed54_boundary--
			Appendix B. Status of This Document [To Be Removed Upon Publication]
			B.1 Discussion Venue
			Comments about this document should be sent directly to the author at
			via <ietf@shaftek.org>.
			B.2 Document Repository
			Copies of this and earlier versions including multiple formats can be
			found at <http://www.shaftek.org/publications/drafts/abuse-report/>.
			B.3 Document History
			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.
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		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		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/