draft-shafranovich-feedback-report-00.txt		draft-shafranovich-feedback-report-01-pre1.txt
	Network Working Group Y. Shafranovich		Network Working Group Y. Shafranovich
	Internet-Draft SolidMatrix Technologies, Inc.		Internet-Draft SolidMatrix Technologies, Inc.
	Expires: September 2, 2005 March 2005		Expires: November 7, 2005 May 6, 2005
	An Extensible Format for Email Feedback Reports		An Extensible Format for Email Feedback Reports
	draft-shafranovich-feedback-report-00.txt		draft-shafranovich-feedback-report-01-pre1.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.
	skipping to change at page 1, line 35		skipping to change at page 1, line 35
	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 2, 2005.		This Internet-Draft will expire on November 7, 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
	replacement for various existing report formats currently used in		replacement for various existing report formats currently used in
	Internet email.		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 . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Format of Email Feedback Reports . . . . . . . . . . . . . . 4		4. Format of Email Feedback Reports . . . . . . . . . . . . . . 4
	5. Format of 'message/feedback-report' Content Type . . . . . . 4		5. Format of 'message/feedback-report' Content Type . . . . . . 5
	6. MIME Type Registration of message/feedback-report . . . . . 5		5.1 Required Fields . . . . . . . . . . . . . . . . . . . . . 5
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6		5.2 Optional Fields Appearing Once . . . . . . . . . . . . . . 5
	8. Security Considerations . . . . . . . . . . . . . . . . . . 6		5.3 Optional Fields Appearing Multiple Times . . . . . . . . . 6
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 6		6. MIME Type Registration of message/feedback-report . . . . . 6
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . 7
	10.1 Normative References . . . . . . . . . . . . . . . . . . 7		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8
	10.2 Informative References . . . . . . . . . . . . . . . . . 7		8.1 Initial Values for the Header Names Registry . . . . . . . 9
	Author's Address . . . . . . . . . . . . . . . . . . . . . . 7		8.2 Initial values for the "Feedback-Type" registry . . . . . 10
	A. Appendix A - An Sample Abuse Report . . . . . . . . . . . . 8		9. Security Considerations . . . . . . . . . . . . . . . . . . 10
	B. Status of This Document [To Be Removed Upon Publication] . . 9		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 10
	B.1 Discussion Venue . . . . . . . . . . . . . . . . . . . . . 9		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	B.2 Document Repository . . . . . . . . . . . . . . . . . . . 9		11.1 Normative References . . . . . . . . . . . . . . . . . . 11
	B.3 Document History . . . . . . . . . . . . . . . . . . . . . 9		11.2 Informative References . . . . . . . . . . . . . . . . . 11
	Intellectual Property and Copyright Statements . . . . . . . 10		Author's Address . . . . . . . . . . . . . . . . . . . . . . 12
			A. Appendix A - An Sample Abuse Report . . . . . . . . . . . . 12
			B. Status of This Document [To Be Removed Upon Publication] . . 13
			B.1 Discussion Venue . . . . . . . . . . . . . . . . . . . . . 13
			B.2 Document Repository and Public Website . . . . . . . . . . 13
			B.3 Document History . . . . . . . . . . . . . . . . . . . . . 13
			Intellectual Property and Copyright Statements . . . . . . . 15
	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 [4]. 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].
	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.		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 [RFC2119].
	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		on public discussion and feedback. Readers are encourages to submit
			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:
	a. To inform ISPs about email abuse originating from their networks		o To inform ISPs about email abuse and viruses originating from or
			related to their networks
	b. To provide feedback to email service providers about abuse		o To provide feedback about abuse complaints to email service
	complaints		providers and relevant third parties (such as reputation
			providers)
	c. To inform the author of the message that the receiver wants to		o To inform email service provides about opt-out requests
	opt out.
	Note that the reports defined in this document are limited to		Please note that while the parent "multipart/report" content type
	providing feedback about email only.		defined in RFC 3462 [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.
	3. Requirements		3. Requirements
	The following requirements are necessary for feedback reports :		The following requirements are necessary for feedback reports (the
			actual standard is defined in the next sections) :
	a. They must be both human and machine readable		o They must be both human and machine readable
	b. Copy of the original email message or email headers must be		o A copy of the original email message (body and headers) or the
	enclosed in order to allow the receiver to properly handle the		message headers must be enclosed in order to allow the receiver to
	report.		properly handle the report.
			o The machine readable section must provide ability for report
			generators to share metadata with receivers,
			o The format must be extensible.
	4. Format of Email Feedback Reports		4. Format of Email Feedback Reports
	An email feedback report is a MIME message with a top level MIME		To satisfy the requirements, an email feedback report is defined as a
	content type of "multipart/report" (as defined in RFC 3462 [1]). The		MIME message with a top level MIME content type of "multipart/report"
	following apply:		(as defined in RFC 3462 [1]). The 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
	"feedback-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 and MUST be included.
	c. The second MIME part of the message contains a machine readable		c. The second MIME part of the message is a machine-readable section
	abuse report with the content type of "message/feedback-report"		with the content type of "message/feedback-report" (defined later
	(defined later on in this document).		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		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 [2]) 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]). This part MUST BE included (unlike
			RFC 3462 [1]).
	e. Each abuse report should related to a single originating message.
	f. The subject line of the abuse report should read as "Email		e. Each feedback report MUST be related to only a SINGLE email
	Feedback Report for IP X.X.X.X" where "X.X.X.X" is the source IP		message. Summary and aggregate formats are outside the scope of
	of the MTA from which the original message was received. If		this specification.
	email authentication is used, the sender may substitute the text
	"for domain YYYYY.ZZZZ" where "YYYYY.ZZZZ" is the authenticated
	domain.
	g. It is preferable that all original email headers are included		f. The subject line of the feedback report SHOULD be the same as the
	even though they are defined as optional in RFC 3462 [1].		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).
	5. Format of 'message/feedback-report' Content Type		5. Format of 'message/feedback-report' Content Type
	The message/feedback-report content type consists of several header		This content type provides a machine-readable section intended to let
	fields as follows:		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.
	a. "Source-IP:" - contains an IPv4 or IPv6 address of the MTA from		The body of this content type consists of multiple "fields" formatted
	which the original message was received.		according to the ABNF of RFC 822 [12] 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.
	b. "Received-Date:" - date the original message was received. This		5.1 Required Fields
	field is formatted in according to the definition in section 3.3
	of RFC 2822 [2]
	c. "Original-Message-ID:" - contains the RFC 2822 [2] Message-ID of
	the original message
	d. "Feedback-Type:" - contains the type of feedback as defined in		The following header fields are REQUIRED and MUST only appear once:
	the corresponding IANA registry.
	e. "Authenticated-Domain:" and "Authenticated-Domain-Method:" -		o "Feedback-Type:" - contains the type of feedback report (as
	defines the authenticated domain and method used for perform that		defined in the corresponding IANA registry). This is intended to
	authentication. The list of method tokens is contained in the		let report generators distinguish among different types of
	corresponding IANA registry. Note that the actual type of		reports.
	authentication used is outside the scope of this document.
			o "User-Agent:" - indicates the name and version of the software
			program that generated the report. The format of this field MUST
			follow section 14.43 of RFC 2616 [3].
			o "Version" - indicates the version of specification that the report
			generator is using to generate the report. The version number in
			this specification is set to "0.1".
			5.2 Optional Fields Appearing Once
			The following header fields are OPTIONAL and MUST NOT appear more
			than once:
			o "Original-Mail-From:" - copy of the email address used in the MAIL
			FROM portion of the original SMTP transaction. The format of this
			field is defined in section 4.1.1.2 of RFC 2821 [4].
			o "Original-Rcpt-To:" - copy of the email address used in the RCPT
			TO portion of the original SMTP transaction. The format of this
			field is defined in section 4.1.1.3 of RFC 2821 [4].
			o "Received-Date:" - indicates the date the original message was
			received by the report generator. This field MUST BE formatted as
			per section 3.3 of RFC 2822 [5].
			o "Source-IP:" - contains an IPv4 or IPv6 address of the MTA from
			which the original message was received. IPv4 addresses are to be
			formatted in dot-decimal notation as currently used by the
			community. IPv6 addresses MUST BE formatted as per section 2.2 of
			RFC 2373 [6].
			5.3 Optional Fields Appearing Multiple Times
			The following set of header fields are OPTIONAL and MAY appear more
			than once:
			o "Authentication-Results:" - indicates the result of an
			authentication check run by the report generator. The format of
			this field is is defined in draft-kucherawy-sender-auth-header
			[7]. Report receivers should note that this field only indicates
			an assertion made by the report generator.
			o "Reported-Domain:" - indicates a domain name that the report
			generator believes to be relevant to the report. Domain format is
			defined in section 2.3.1 of RFC 1035 [8].
			o "Reported-URI:" - indicates a URI that the report generator
			believes to be relevant to the report. URI format is defined in
			RFC 2396 [13].
			o "Removal-Recipient:" - indicates the email address to be removed
			from the mailing list (only used with "opt-out" feedback report).
			The format of this field is defined in section 3.4.1 of RFC 2822
			[5].
	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 [4], 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 5, line 41		skipping to change at page 7, line 21
	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.
	Security considerations:		Security considerations:
	See section 3 of RFC 3462 [1]		See the "Security Considerations" of this document.
	Interoperability considerations: none		Interoperability considerations: implementors MUST ignore any fields
			they do not support
	Published specification: this document		Published specification: this document
	Applications which use this media type: Abuse helpdesk software for		Applications which use this media type: Abuse helpdesk software for
	ISPs		ISPs
	Additional information:		Additional information:
	Magic number(s): none		Magic number(s): none
	skipping to change at page 6, line 19		skipping to change at page 7, line 47
	Macintosh File Type Code(s): none		Macintosh File Type Code(s): none
	Person and 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. Extensibility
			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.
			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 for "Feedback-Type" and "Authentication-Domain-		setup two registries: one for header field names and a second for
	Method" headers. Below are the initial values for these registries.		"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 [9]. Any new field registered is considered
			OPTIONAL unless a new version of this specifiction is published.
	Initial values for the "Feedback-Type" registry:		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:
	abuse - spam or some other kind of email abuse		1. Name of the field being registered
	opt-out - a request to opt out from a mailing list.		2. Short description of the field
	virus - report of a virus found in the originating message		3. Whether the field can appear more than once
	Initial values for the "Authentication-Domain-Method" registry:		4. Which "Feedback-Type" types does this field apply to (or "any")
	domainkeys - as defined in delany-domainkeys-base [5]		5. The RFC number (or Internet draft name) in which this header is
			registered
	iim - as defined in fenton-identified-mail [6]		If the header field being registered requires its own IANA registry,
			than the appropriate registry MUST be properly defined.
	sender-id - as defined in lyon-senderid-core [7]		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:
	spf - as defined in schlitt-spf-classic [8]		1. Name of the feedback type being registered
	8. Security Considerations		2. Short description
			3. The RFC number (or Internet draft name) in which this feedback
			type is registered
			8.1 Initial Values for the Header Names Registry
			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
			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
			8.2 Initial values for the "Feedback-Type" registry
			The initial names and descriptions are provided below. The RFC
			number used for registration of these values is this document.
			o abuse - spam or some other kind of email abuse
			o opt-out - a request to opt out from a mailing list.
			o virus - report of a virus found in the originating message
			9. Security Considerations
	See section 3 of RFC 3462 [1]		See section 3 of RFC 3462 [1]
	9. 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.
	10. References		11. References
	10.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] Resnick, P., "Internet Message Format", RFC 2822, April 2001.		[2] 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,		Extensions (MIME) Part Two: Media Types", RFC 2046,
	November 1996.		November 1996.
	10.2 Informative References		[3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
			Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
			HTTP/1.1", RFC 2616, June 1999.
	[4] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet		[4] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
	Mail Extensions (MIME) Part Four: Registration Procedures",		April 2001.
	BCP 13, RFC 2048, November 1996.
	[5] Delany, M., "Domain-based Email Authentication Using Public-Keys		[5] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
	Advertised in the DNS (DomainKeys)",
	draft-delany-domainkeys-base-02 (work in progress), March 2005.
	[6] Fenton, J. and M. Thomas, "Identified Internet Mail",		[6] Hinden, R. and S. Deering, "IP Version 6 Addressing
	draft-fenton-identified-mail-01 (work in progress),		Architecture", RFC 2373, July 1998.
	October 2004.
	[7] Lyon, J., "Sender ID: Authenticating E-Mail",		[7] Kucherawy, M., "Message Header for Indicating Sender
	draft-lyon-senderid-core-00 (work in progress), November 2004.		Authentication Status", draft-kucherawy-sender-auth-header-02
			(work in progress), May 2005.
	[8] Wong, M., "Sender Policy Framework: Authorizing Use of Domains		[8] Mockapetris, P., "Domain names - implementation and
	in E-MAIL", draft-schlitt-spf-classic-00 (work in progress),		specification", STD 13, RFC 1035, November 1987.
	January 2005.
			[9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
			Considerations Section in RFCs", BCP 26, RFC 2434,
			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] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
			Mail Extensions (MIME) Part Four: Registration Procedures",
			BCP 13, RFC 2048, November 1996.
			[12] Crocker, D., "Standard for the format of ARPA Internet text
			messages", STD 11, RFC 822, August 1982.
			[13] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
			Resource Identifiers (URI): Generic Syntax", RFC 2396,
			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 - 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: 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.
	--part1_13d.2e68ed54_boundary		--part1_13d.2e68ed54_boundary
	Content-Type: message/feedback-report		Content-Type: message/feedback-report