draft-shafranovich-feedback-report-01-pre1.txt		draft-shafranovich-feedback-report-01.txt
	Network Working Group Y. Shafranovich		Network Working Group Y. Shafranovich
	Internet-Draft SolidMatrix Technologies, Inc.		Internet-Draft SolidMatrix Technologies, Inc.
	Expires: November 7, 2005 May 6, 2005		Expires: November 14, 2005 May 13, 2005
	An Extensible Format for Email Feedback Reports		An Extensible Format for Email Feedback Reports
	draft-shafranovich-feedback-report-01-pre1.txt		draft-shafranovich-feedback-report-01.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		By submitting this Internet-Draft, each author represents that any
	of Section 3 of RFC 3667. By submitting this Internet-Draft, each		applicable patent or other IPR claims of which he or she is aware
	author represents that any applicable patent or other IPR claims of		have been or will be disclosed, and any of which he or she becomes
	which he or she is aware have been or will be disclosed, and any of		aware will be disclosed, in accordance with Section 6 of BCP 79.
	which he or she become aware will be disclosed, in accordance with
	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 Internet-		other groups may also distribute working documents as 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 November 7, 2005.		This Internet-Draft will expire on November 14, 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 feedback about received email to		used by network operators to report feedback about received email to
	other parties. This format is intended as a machine readable		other parties. This format is intended as a machine readable
	skipping to change at page 2, line 13		skipping to change at page 2, line 13
	Internet email.		Internet email.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Intent . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Intent . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Format of Email Feedback Reports . . . . . . . . . . . . . . 4		4. Format of Email Feedback Reports . . . . . . . . . . . . . . 4
	5. Format of 'message/feedback-report' Content Type . . . . . . 5		5. Format of 'message/feedback-report' Content Type . . . . . . 5
	5.1 Required Fields . . . . . . . . . . . . . . . . . . . . . 5		5.1 Required Fields . . . . . . . . . . . . . . . . . . . . . 5
	5.2 Optional Fields Appearing Once . . . . . . . . . . . . . . 5		5.2 Optional Fields Appearing Once . . . . . . . . . . . . . . 6
	5.3 Optional Fields Appearing Multiple Times . . . . . . . . . 6		5.3 Optional Fields Appearing Multiple Times . . . . . . . . . 6
	6. MIME Type Registration of message/feedback-report . . . . . 6		6. MIME Type Registration of message/feedback-report . . . . . 7
	7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . 7		7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . 8
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8
	8.1 Initial Values for the Header Names Registry . . . . . . . 9		8.1 Initial Values for the Header Names Registry . . . . . . . 9
	8.2 Initial values for the "Feedback-Type" registry . . . . . 10		8.2 Initial values for the "Feedback-Type" registry . . . . . 10
	9. Security Considerations . . . . . . . . . . . . . . . . . . 10		9. Security Considerations . . . . . . . . . . . . . . . . . . 11
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 10		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	11.1 Normative References . . . . . . . . . . . . . . . . . . 11		11.1 Normative References . . . . . . . . . . . . . . . . . . 11
	11.2 Informative References . . . . . . . . . . . . . . . . . 11		11.2 Informative References . . . . . . . . . . . . . . . . . 12
	Author's Address . . . . . . . . . . . . . . . . . . . . . . 12		Author's Address . . . . . . . . . . . . . . . . . . . . . . 12
	A. Appendix A - An Sample Abuse Report . . . . . . . . . . . . 12		A. Appendix A - Sample Feedback Reports . . . . . . . . . . . . 12
	B. Status of This Document [To Be Removed Upon Publication] . . 13		A.1 Simple Report for Email Abuse without Optional Headers . . 12
	B.1 Discussion Venue . . . . . . . . . . . . . . . . . . . . . 13		A.2 Opt-Out Report without Message Body . . . . . . . . . . . 13
	B.2 Document Repository and Public Website . . . . . . . . . . 13		A.3 Full Report for Email Abuse with All Headers . . . . . . . 14
	B.3 Document History . . . . . . . . . . . . . . . . . . . . . 13		B. Status of This Document [To Be Removed Upon Publication] . . 16
	Intellectual Property and Copyright Statements . . . . . . . 15		B.1 Discussion Venue . . . . . . . . . . . . . . . . . . . . . 16
			B.2 Document Repository and Public Website . . . . . . . . . . 16
			B.3 Document History . . . . . . . . . . . . . . . . . . . . . 16
			B.4 Outstanding Issues . . . . . . . . . . . . . . . . . . . . 17
			Intellectual Property and Copyright Statements . . . . . . . 19
	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. In addition, many		software to interpret the many types of them. In addition, many
	operators use various other report formats to provide non-abuse		operators use various other report formats to provide non-abuse
	feedback about processed email. This memo seeks to define a standard		feedback about processed email. This memo seeks to define a standard
	extensible format and the "message/feedback-report" MIME type for		extensible format and the "message/feedback-report" MIME type for
	these reports in accordance with RFC 2048 [11]. This format and		these reports in accordance with RFC 2048 [11]. This format and
	content type is intended to be used within the scope of the framework		content type is intended to be used within the scope of the framework
	of the "multipart/report" content type defined in RFC 3462 [1].		of the "multipart/report" content type defined in RFC 3462 [1].
			While there have been previous work in this area([12] and [13]), 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		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,
	how trust among report senders and receivers is established, and		how trust among report senders and receivers is established, and
	reports related to more than one message are outside the scope of		reports related to more than one message are outside the scope of
	this document.		this document.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in RFC 2119 [2].
	NOTE: This document may be incomplete and is intented to evolve based		NOTE: This document may be incomplete and is intented to evolve based
	on public discussion and feedback. Readers are encourages to submit		on public discussion and feedback. Readers are encourages to submit
	their comments and suggestions.		their comments and suggestions.
	2. Intent		2. Intent
	The reports defined in this document are intended for several		The reports defined in this document are intended for several
	purposes:		purposes:
	o To inform ISPs about email abuse and viruses originating from or		o To inform ISPs about email abuse originating from or related to
	related to their networks		their networks
	o To provide feedback about abuse complaints to email service		o To provide feedback about abuse complaints to email service
	providers and relevant third parties (such as reputation		providers and relevant third parties (such as reputation
	providers)		providers)
	o To inform email service provides about opt-out requests		o To inform email service provides about opt-out requests
	Please note that while the parent "multipart/report" content type		Please note that while the parent "multipart/report" content type
	defined in RFC 3462 [1] is used for all kinds of administrative		defined in RFC 3462 [1] is used for all kinds of administrative
	messages, this format is intended specifically for communications		messages, this format is intended specifically for communications
	among providers regarding email abuse and related issues, and SHOULD		among providers regarding email abuse and related issues, and SHOULD
	NOT be used for other reports.		NOT be used for other reports.
	3. Requirements		3. Requirements
	skipping to change at page 4, line 16		skipping to change at page 4, line 23
	The following requirements are necessary for feedback reports (the		The following requirements are necessary for feedback reports (the
	actual standard is defined in the next sections) :		actual standard is defined in the next sections) :
	o They must be both human and machine readable		o They must be both human and machine readable
	o A copy of the original email message (body and headers) or the		o A copy of the original email message (body and headers) or the
	message headers must be enclosed in order to allow the receiver to		message headers must be enclosed in order to allow the receiver to
	properly handle the report.		properly handle the report.
	o The machine readable section must provide ability for report		o The machine readable section must provide ability for the report
	generators to share metadata with receivers,		generators to share metadata with receivers,
	o The format must be extensible.		o The format must be extensible.
	4. Format of Email Feedback Reports		4. Format of Email Feedback Reports
	To satisfy the requirements, an email feedback report is defined as a		To satisfy the requirements, an email feedback report is defined as a
	MIME message with a top level MIME content type of "multipart/report"		MIME message with a top level MIME content type of "multipart/report"
	(as defined in RFC 3462 [1]). The following apply:		(as defined in RFC 3462 [1]). The following apply:
	skipping to change at page 4, line 41		skipping to change at page 4, line 48
	description of the report and MUST be included.		description of the report and MUST be included.
	c. The second MIME part of the message is a machine-readable section		c. The second MIME part of the message is a machine-readable section
	with the content type of "message/feedback-report" (defined later		with the content type of "message/feedback-report" (defined later
	on in this document) and MUST be included. This section is		on in this document) and MUST be included. This section is
	intended to convey metadata about the report in question that may		intended to convey metadata about the report in question that may
	not be readily available from the included email message itself.		not be readily available from the included email message itself.
	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 [2]) OR a copy of the headers from the		(as defined in RFC 2046 [3]) 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]). This part MUST BE included (unlike		(as defined in RFC 3462 [1]). This part MUST BE included (unlike
	RFC 3462 [1]).		RFC 3462 [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		e. Each feedback report MUST be related to only a SINGLE email
	message. Summary and aggregate formats are outside the scope of		message. Summary and aggregate formats are outside the scope of
	this specification.		this specification.
	f. The subject line of the feedback report SHOULD be the same as the		f. The subject line of the feedback report SHOULD be the same as the
	included email message and MAY include only the standard		included email message and MAY include only the standard
	forwarding prefix used by MUAs such as "FW:" (many smaller		forwarding prefix used by MUAs such as "FW:" (many smaller
	operators using MUAs for abuse handling rely on the subject lines		operators using MUAs for abuse handling rely on the subject lines
	for processing).		for processing).
	5. Format of 'message/feedback-report' Content Type		5. Format of 'message/feedback-report' Content Type
	This content type provides a machine-readable section intended to let		This content type provides a machine-readable section intended to let
	the report generator convey metadata to the report receiver. The		the report generator convey metadata to the report receiver. The
	intent of this section is it allow report generators to convey		intent of this section is it allow report generators to convey
	metadata to report receivers that may not available or may not be		metadata to report receivers that may not available or may not be
	readily available from the originating email message or headers.		readily available from the originating email message or headers.
	The body of this content type consists of multiple "fields" formatted		The body of this content type consists of multiple "fields" formatted
	according to the ABNF of RFC 822 [12] header "fields". This section		according to the ABNF of RFC 822 [14] header "fields". This section
	defines the initial set of fields provided by this specification.		defines the initial set of fields provided by this specification.
	Additional fields maybe registered according to the procedure		Additional fields maybe registered according to the procedure
	described later on in this document. Note that these fields		described later on in this document. Note that these fields
	represent information that the receiver is asserting about the report		represent information that the receiver is asserting about the report
	in question, but are not necessarily verifiable. Report receivers		in question, but are not necessarily verifiable. Report receivers
	MUST NOT assume that these assertions are always true.		MUST NOT assume that these assertions are always true.
	5.1 Required Fields		5.1 Required Fields
	The following header fields are REQUIRED and MUST only appear once:		The following header fields are REQUIRED and MUST only appear once:
	o "Feedback-Type:" - contains the type of feedback report (as		o "Feedback-Type:" - contains the type of feedback report (as
	defined in the corresponding IANA registry). This is intended to		defined in the corresponding IANA registry). This is intended to
	let report generators distinguish among different types of		let report generators distinguish among different types of
	reports.		reports.
	o "User-Agent:" - indicates the name and version of the software		o "User-Agent:" - indicates the name and version of the software
	program that generated the report. The format of this field MUST		program that generated the report. The format of this field MUST
	follow section 14.43 of RFC 2616 [3].		follow section 14.43 of RFC 2616 [4].
	o "Version" - indicates the version of specification that the report		o "Version" - indicates the version of specification that the report
	generator is using to generate the report. The version number in		generator is using to generate the report. The version number in
	this specification is set to "0.1".		this specification is set to "0.1".
	5.2 Optional Fields Appearing Once		5.2 Optional Fields Appearing Once
	The following header fields are OPTIONAL and MUST NOT appear more		The following header fields are OPTIONAL and MUST NOT appear more
	than once:		than once:
	o "Original-Mail-From:" - copy of the email address used in the MAIL		o "Original-Mail-From:" - copy of the email address used in the MAIL
	FROM portion of the original SMTP transaction. The format of this		FROM portion of the original SMTP transaction. The format of this
	field is defined in section 4.1.1.2 of RFC 2821 [4].		field is defined in section 4.1.1.2 of RFC 2821 [5].
	o "Original-Rcpt-To:" - copy of the email address used in the RCPT		o "Original-Rcpt-To:" - copy of the email address used in the RCPT
	TO portion of the original SMTP transaction. The format of this		TO portion of the original SMTP transaction. The format of this
	field is defined in section 4.1.1.3 of RFC 2821 [4].		field is defined in section 4.1.1.3 of RFC 2821 [5].
	o "Received-Date:" - indicates the date the original message was		o "Received-Date:" - indicates the date the original message was
	received by the report generator. This field MUST BE formatted as		received by the report generator. This field MUST BE formatted as
	per section 3.3 of RFC 2822 [5].		per section 3.3 of RFC 2822 [6].
	o "Source-IP:" - contains an IPv4 or IPv6 address of the MTA from		o "Source-IP:" - contains an IPv4 or IPv6 address of the MTA from
	which the original message was received. IPv4 addresses are to be		which the original message was received. IPv4 addresses are to be
	formatted in dot-decimal notation as currently used by the		formatted in dot-decimal notation as currently used by the
	community. IPv6 addresses MUST BE formatted as per section 2.2 of		community. IPv6 addresses MUST BE formatted as per section 2.2 of
	RFC 2373 [6].		RFC 2373 [7].
	5.3 Optional Fields Appearing Multiple Times		5.3 Optional Fields Appearing Multiple Times
	The following set of header fields are OPTIONAL and MAY appear more		The following set of header fields are OPTIONAL and MAY appear more
	than once:		than once:
	o "Authentication-Results:" - indicates the result of an		o "Authentication-Results:" - indicates the result of an
	authentication check run by the report generator. The format of		authentication check run by the report generator. The format of
	this field is is defined in draft-kucherawy-sender-auth-header		this field is is defined in draft-kucherawy-sender-auth-header
	[7]. Report receivers should note that this field only indicates		[8]. Report receivers should note that this field only indicates
	an assertion made by the report generator.		an assertion made by the report generator.
	o "Reported-Domain:" - indicates a domain name that the report		o "Reported-Domain:" - indicates a domain name that the report
	generator believes to be relevant to the report. Domain format is		generator believes to be relevant to the report. Domain format is
	defined in section 2.3.1 of RFC 1035 [8].		defined in section 2.3.1 of RFC 1035 [9].
	o "Reported-URI:" - indicates a URI that the report generator		o "Reported-URI:" - indicates a URI that the report generator
	believes to be relevant to the report. URI format is defined in		believes to be relevant to the report. URI format is defined in
	RFC 2396 [13].		RFC 2396 [15].
	o "Removal-Recipient:" - indicates the email address to be removed		o "Removal-Recipient:" - indicates the email address to be removed
	from the mailing list (only used with "opt-out" feedback report).		from the mailing list (MUST only be used with "opt-out" and "opt-
	The format of this field is defined in section 3.4.1 of RFC 2822		out-list" types). The format of this field is defined in section
	[5].		3.4.1 of RFC 2822 [6].
	6. MIME Type Registration of message/feedback-report		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 [11], which will be submitted to IANA after IESG approval of		RFC 2048 [11], 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/feedback-report		Subject: Registration of MIME media types message/feedback-report
	MIME media type name: message		MIME media type name: message
	MIME subtype name: feedback-report		MIME subtype name: feedback-report
	Required parameters: none		Required parameters: none
	Optional parameters: none		Optional parameters: none
	skipping to change at page 8, line 27		skipping to change at page 8, line 38
	8. IANA Considerations		8. IANA Considerations
	After IESG approval, IANA is expected to register MIME type "message/		After IESG approval, IANA is expected to register MIME type "message/
	feedback-report" using the application provided in this document and		feedback-report" using the application provided in this document and
	setup two registries: one for header field names and a second for		setup two registries: one for header field names and a second for
	"Feedback-Type" values. This section contains the templates used for		"Feedback-Type" values. This section contains the templates used for
	registration of new entries in these registries and initial values.		registration of new entries in these registries and initial values.
	New registrations to these two registries MUST have approval by an		New registrations to these two registries MUST have approval by an
	Designated Expert in accordance with the Expert Review guidelines as		Designated Expert in accordance with the Expert Review guidelines as
	described in RFC 2434 [9]. Any new field registered is considered		described in RFC 2434 [10] (the expert should be appointed by the
	OPTIONAL unless a new version of this specifiction is published.		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		For the header name registry, the following MUST be provided in an
	RFC publication (or Internet draft with IETF consensus or IESG		RFC publication (or Internet draft with IETF consensus or IESG
	approval) in order to register a new header field name:		approval) in order to register a new header field name:
	1. Name of the field being registered		1. Name of the field being registered
	2. Short description of the field		2. Short description of the field
	3. Whether the field can appear more than once		3. Whether the field can appear more than once
	skipping to change at page 10, line 9		skipping to change at page 10, line 21
	Related "Feedback-Type": any		Related "Feedback-Type": any
	Field Name: Reported-URI		Field Name: Reported-URI
	Description: relevant URI		Description: relevant URI
	Multiple Appearances: Yes		Multiple Appearances: Yes
	Related "Feedback-Type": any		Related "Feedback-Type": any
	Field Name: Removal-Recipient		Field Name: Removal-Recipient
	Description: email address to be removed from the mailing list		Description: email address to be removed from the mailing list
	Multiple Appearances: Yes		Multiple Appearances: Yes
	Related "Feedback-Type": opt-out		Related "Feedback-Type": opt-out, opt-out-list
	Field Name: Source-IP		Field Name: Source-IP
	Description: IPv4 or IPv6 address from which the original message was		Description: IPv4 or IPv6 address from which the original message was
	received		received
	Multiple Appearances: No		Multiple Appearances: No
	Related "Feedback-Type": any		Related "Feedback-Type": any
	Field Name: User-Agent		Field Name: User-Agent
	Description: name and version of the program used		Description: name and version of the program used
	Multiple Appearances: No		Multiple Appearances: No
	skipping to change at page 10, line 34		skipping to change at page 10, line 46
	Multiple Appearances: No		Multiple Appearances: No
	Related "Feedback-Type": any		Related "Feedback-Type": any
	8.2 Initial values for the "Feedback-Type" registry		8.2 Initial values for the "Feedback-Type" registry
	The initial names and descriptions are provided below. The RFC		The initial names and descriptions are provided below. The RFC
	number used for registration of these values is this document.		number used for registration of these values is this document.
	o abuse - spam or some other kind of email abuse		o abuse - spam or some other kind of email abuse
	o opt-out - a request to opt out from a mailing list.		o fraud - indicates some kind of fraud or phishing activity.
			o opt-out - a request to opt out from ALL mailing lists from this
			provider.
			o opt-out-list - a request to opt out from THIS mailing list ONLY.
			o other - any other feedback that doesn't fit into other types.
	o virus - report of a virus found in the originating message		o virus - report of a virus found in the originating message
	9. Security Considerations		9. Security Considerations
	See section 3 of RFC 3462 [1]		See section 3 of RFC 3462 [1]
	10. Acknowledgments		10. Acknowledgments
	The author would like to thank many of the members of the email		The author would like to thank many of the members of the email
	community who provided helpful comments and suggestions for this		community who provided helpful comments and suggestions for this
	document including many of the participants in ASRG, IETF and MAAWG		document including many of the participants in ASRG, IETF and MAAWG
	activities.		activities, and all of the members of the abuse-feedback-report
			public mailing list.
	11. References		11. References
	11.1 Normative References		11.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] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
			Levels", BCP 14, RFC 2119, March 1997.
			[3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part Two: Media Types", RFC 2046,		Extensions (MIME) Part Two: Media Types", RFC 2046,
	November 1996.		November 1996.
	[3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,		[4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
	Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --		Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
	HTTP/1.1", RFC 2616, June 1999.		HTTP/1.1", RFC 2616, June 1999.
	[4] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,		[5] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
	April 2001.		April 2001.
	[5] Resnick, P., "Internet Message Format", RFC 2822, April 2001.		[6] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
	[6] Hinden, R. and S. Deering, "IP Version 6 Addressing		[7] Hinden, R. and S. Deering, "IP Version 6 Addressing
	Architecture", RFC 2373, July 1998.		Architecture", RFC 2373, July 1998.
	[7] Kucherawy, M., "Message Header for Indicating Sender		[8] Kucherawy, M., "Message Header for Indicating Sender
	Authentication Status", draft-kucherawy-sender-auth-header-02		Authentication Status", draft-kucherawy-sender-auth-header-02
	(work in progress), May 2005.		(work in progress), May 2005.
	[8] Mockapetris, P., "Domain names - implementation and		[9] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, November 1987.		specification", STD 13, RFC 1035, November 1987.
	[9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA		[10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
	Considerations Section in RFCs", BCP 26, RFC 2434,		Considerations Section in RFCs", BCP 26, RFC 2434,
	October 1998.		October 1998.
	[10] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.
	11.2 Informative References		11.2 Informative References
	[11] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet		[11] 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.
	[12] Crocker, D., "Standard for the format of ARPA Internet text		[12] Crissman, G., "Proposed Spam Reporting BCP Document", May 2005,
			<http://www.tmisnet.com/~strads/spam/bcp.html>.
			[13] Anti-Spam Research Group (ASRG) of the Internet Research Task
			Force (IRTF), "Abuse Reporting Standards Subgroup of the ASRG",
			May 2005, <http://asrg.sp.am/subgroups/abuse_reports.shtml>.
			[14] Crocker, D., "Standard for the format of ARPA Internet text
	messages", STD 11, RFC 822, August 1982.		messages", STD 11, RFC 822, August 1982.
	[13] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[15] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifiers (URI): Generic Syntax", RFC 2396,		Resource Identifiers (URI): Generic Syntax", RFC 2396,
	August 1998.		August 1998.
	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 - Sample Feedback Reports
			A.1 Simple Report for Email Abuse without Optional Headers
	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: FW: Earn money		Subject: FW: Earn money
	To: <abuse@example.net>		To: <abuse@example.net>
	MIME-Version: 1.0		MIME-Version: 1.0
	Content-Type: multipart/report; report-type=feedback-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.
			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--
			A.2 Opt-Out Report without Message Body
			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--
			A.3 Full Report for Email Abuse with All Headers
			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		--part1_13d.2e68ed54_boundary
	Content-Type: message/feedback-report		Content-Type: message/feedback-report
	Feedback-Type: abuse		Feedback-Type: abuse
	User-Agent: SomeGenerator/1.0		User-Agent: SomeGenerator/1.0
	Version: 0.1		Version: 0.1
	Original-Mail-From: <somespammer@example.net>		Original-Mail-From: <somespammer@example.net>
	Original-Rcpt-To: <user@example.com>		Original-Rcpt-To: <user@example.com>
	Received-Date: Thu, 8 Mar 2005 14:00:00 EDT		Received-Date: Thu, 8 Mar 2005 14:00:00 EDT
	skipping to change at page 13, line 39		skipping to change at page 16, line 25
	B.2 Document Repository and Public Website		B.2 Document Repository and Public Website
	Copies of this and earlier versions including multiple formats can be		Copies of this and earlier versions including multiple formats can be
	found at <http://www.shaftek.org/publications/drafts/abuse-report/>.		found at <http://www.shaftek.org/publications/drafts/abuse-report/>.
	A public website regarding this draft and related efforts is located		A public website regarding this draft and related efforts is located
	at <http://mipassoc.org/arf/>.		at <http://mipassoc.org/arf/>.
	B.3 Document History		B.3 Document History
			Changes from draft-shafranovich-feedback-report-01-pre1 to
			draft-shafranovich-feedback-report-01:
			o Added an "Outstanding Issues" section.
			o Minor spelling mistakes and clarifications.
			o Added links to previous work and more examples.
			o 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		Changes from draft-shafranovich-feedback-report-00 to
	draft-shafranovich-feedback-report-01-pre1:		draft-shafranovich-feedback-report-01-pre1:
	o Changed the introduction section< to clarify specific points that		o Changed the introduction section to clarify specific points that
	are out of scope for this document		are out of scope for this document
	o Added pointers to a public mailing list for discussion and public		o Added pointers to a public mailing list for discussion and public
	web page		web page
	o Clarified the intent section and added some extra points to it		o Clarified the intent section and added some extra points to it
	o Added a reference to RFC 2119 and changed the document to comply		o Added a reference to RFC 2119 and changed the document to comply
	o Made it clear that the requirements section) is not the one		o Made it clear that the requirements section) is not the one
	defining the standard		defining the standard
	o Clarified the main format section to make all three parts		o Clarified the main format section to make all three parts
	mandatory		mandatory
	o Changed section 4f regarding subject lines to mandate that subject		o Changed section 4f regarding subject lines to mandate that subject
	lines should be left intact. Removed the convention for subject		lines should be left intact. Removed the convention for subject
	lines that was defined in the previous version		lines that was defined in the previous version
	o Added text to the the machine readable section clarifying its		o Added text to the the machine readable section clarifying its
	intent. Also added RFC 2119 references, reorganized fields,		intent. Also added RFC 2119 references, reorganized fields,
	indicated whether specific header fields can appear more than once		indicated whether specific header fields can appear more than once
	skipping to change at page 15, line 4		skipping to change at page 17, line 37
	Changes from draft-shafranovich-abuse-report-00 to		Changes from draft-shafranovich-abuse-report-00 to
	draft-shafranovich-feedback-report-00:		draft-shafranovich-feedback-report-00:
	o Name of the format and report changed to 'feedback-report'		o Name of the format and report changed to 'feedback-report'
	o Minor spelling corrections		o Minor spelling corrections
	o Added authentication headers and registry		o Added authentication headers and registry
	o Added feedback-type header and registry.		o Added feedback-type header and registry.
			B.4 Outstanding Issues
			Here is a list of some outstanding issues for this document that have
			not been finalized:
			o Whether encoding of the machine readable part should be limited to
			7-bit
			o 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.
			o Whether the "from" address should be required to be a human just
			like other RFCs in the "message/report" family.
			o Whether there is a need for a new header to indicate munging of
			the included email message.
			o Whether different type of convention should be allowed for subject
			lines.
			o 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.
	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/