< draft-vaudreuil-1892bis-01.txt		draft-vaudreuil-1892bis-02.txt >
			A new Request for Comments is now available in online RFC libraries.
	Internet Draft Greg Vaudreuil		RFC 3462
	Expires in six months Lucent Technologies
	April 16, 2002
	The Multipart/Report Content Type
	for the Reporting of
	Mail System Administrative Messages
	<draft-vaudreuil-1892bis-01.txt>
	Status of this Memo
	This document is an Internet-Draft and is in full conformance with all
	provisions of Section 10 of RFC 2026.
	This document is an Internet Draft. Internet Drafts are working
	documents of the Internet Engineering Task Force (IETF), its Areas,
	and its Working Groups. Note that other groups may also distribute
	working documents as Internet Drafts.
	Internet Drafts are valid for a maximum of six months and may be
	updated, replaced, or obsoleted by other documents at any time. It is
	inappropriate to use Internet Drafts as reference material or to cite
	them other than as a "work in progress".
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/1id-abstracts.html
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html
	Copyright Notice
	Copyright (C) The Internet Society (2002). All Rights Reserved.
	This Internet-Draft is in conformance with Section 10 of RFC 2026.
	Abstract
	The Multipart/Report MIME content-type is a general "family" or
	"container" type for electronic mail reports of any kind. Although
	this memo defines only the use of the Multipart/Report content-type
	with respect to delivery status reports, mail processing programs will
	benefit if a single content-type is used to for all kinds of reports.
	This document is part of a four document set describing the delivery
	status report service. This collection includes the SMTP extensions
	to request delivery status reports, a MIME content for the reporting
	of delivery reports, an enumeration of extended status codes, and this
	document describing a multipart container for the delivery report, the
	original message, and a human-friendly summary of the failure.
	Working Group Summary
	RFC 1892 was a product of the Notary working group. This document is
	a revision of that document providing clarifications as necessary to
	advance to draft standard.
	Document Conventions
	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 RFC-2119 [RFC2119].
	Table of Contents
	1. THE MULTIPART/REPORT CONTENT TYPE.................................3
	2. THE TEXT/RFC822-HEADERS...........................................4
	3. SECURITY CONSIDERATIONS...........................................5
	4. REFERENCES........................................................5
	5. COPYRIGHT NOTICE..................................................6
	6. AUTHOR'S ADDRESS..................................................6
	APPENDIX A - CHANGES FROM RFC1893....................................7
	1. The Multipart/Report Content Type
	The Multipart/Report MIME content-type is a general "family" or
	"container" type for electronic mail reports of any kind. Although
	this memo defines only the use of the Multipart/Report content-type
	with respect to delivery status reports, mail processing programs will
	benefit if a single content-type is used to for all kinds of reports.
	The Multipart/Report content-type is defined as follows:
	MIME type name: multipart
	MIME subtype name: report
	Required parameters: boundary, report-type
	Optional parameters: none
	Encoding considerations: 7bit should always be adequate
	Security considerations: see section 4 of this memo.
	The syntax of Multipart/Report is identical to the Multipart/Mixed
	content type defined in [MIME]. When used to send a report, the
	Multipart/Report content-type must be the top-level MIME content type
	for any report message. The report-type parameter identifies the type
	of report. The parameter is the MIME content sub-type of the second
	body part of the Multipart/Report.
	User agents and gateways must be able to automatically determine
	that a message is a mail system report and should be processed as
	such. Placing the Multipart/Report as the outermost content
	provides a mechanism whereby an auto-processor may detect through
	parsing the RFC 822 headers that the message is a report.
	The Multipart/Report content-type contains either two or three sub-
	parts, in the following order:
	1) [Required] The first body part contains human readable message. The
	purpose of this message is to provide an easily understood description
	of the condition(s) that caused the report to be generated, for a
	human reader who may not have an user agent capable of interpreting
	the second section of the Multipart/Report.
	The text in the first section may be in any MIME standards-track
	content-type, charset, or language. Where a description of the error
	is desired in several languages or several media, a
	Multipart/Alternative construct may be used.
	This body part may also be used to send detailed information that
	cannot be easily formatted into a Message/Report body part.
	(2) [Required] A machine parsable body part containing an account of
	the reported message handling event. The purpose of this body part is
	to provide a machine-readable description of the condition(s) that
	caused the report to be generated, along with details not present in
	the first body part that may be useful to human experts. An initial
	body part, Message/delivery-status is defined in [DSN]
	(3) [Optional] A body part containing the returned message or a
	portion thereof. This information may be useful to aid human experts
	in diagnosing problems. (Although it may also be useful to allow the
	sender to identify the message which the report was issued, it is
	hoped that the envelope-id and original-recipient- address returned in
	the Message/Report body part will replace the traditional use of the
	returned content for this purpose.)
	Return of content may be wasteful of network bandwidth and a variety
	of implementation strategies can be used. Generally the sender should
	choose the appropriate strategy and inform the recipient of the
	required level of returned content required. In the absence of an
	explicit request for level of return of content such as that provided
	in [DRPT], the agent that generated the delivery service report should
	return the full message content.
	When data not encoded in 7 bits is to be returned, and the return path
	is not guaranteed to be 8-bit capable, two options are available. The
	original message MAY be re-encoded into a legal 7-bit MIME message or
	the Text/RFC822-Headers content-type MAY be used to return only the
	original message headers.
	2. The Text/RFC822-Headers content-type
	The Text/RFC822-Headers MIME content-type provides a
	mechanism to label and return only the RFC 822 headers of
	a failed message. These headers are not the complete
	message and should not be returned as a Message/RFC822.
	The returned headers are useful for identifying the
	failed message and for diagnostics based on the received:
	lines.
	The Text/RFC822-Headers content-type is defined as follows:
	MIME type name: Text
	MIME subtype name: RFC822-Headers
	Required parameters: None
	Optional parameters: none
	Encoding considerations: 7 bit is sufficient for normal RFC822
	headers, however, if the headers are broken and require
	encoding to make them legal 7 bit content, they may be
	encoded in quoted-printable.
	Security considerations: see section 3 of this memo.
	The Text/RFC822-headers body part should contain all the RFC822 header
	lines from the message which caused the report. The RFC822 headers
	include all lines prior to the blank line in the message. They include
	the MIME-Version and MIME Content- headers.
	3. Security Considerations
	Automated use of report types without authentication presents several
	security issues. Forging negative reports presents the opportunity
	for denial-of-service attacks when the reports are used for automated
	maintenance of directories or mailing lists. Forging positive reports
	may cause the sender to incorrectly believe a message was delivered
	when it was not
	4. References
	[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
	USC/Information Sciences Institute, August 1982.
	[DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
	Delivery Status Notifications", RFC 1894, University of Tennessee,
	Octel Network Services, January 1996.
	[RFC822] Crocker, D., "Standard for the format of ARPA Internet Text
	Messages", STD 11, RFC 822, UDEL, August 1982.
	[MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
	Extensions", RFC 1521, Bellcore, Innosoft, June 1992.
	[DRPT] Moore, K., "SMTP Service Extension for Delivery Status		Title: The Multipart/Report Content Type for the
	Notifications", RFC 1891, University of Tennessee, January 1996.		Reporting of Mail System Administrative Messages
			Author(s): G. Vaudreuil
			Status: Standards Track
			Date: Janaury 2003
			Mailbox: GregV@ieee.org
			Pages: 7
			Characters: 12186
			Obsoletes: 1892
	5. Copyright Notice		I-D Tag: draft-vaudreuil-1892bis-02.txt
	"Copyright (C) The Internet Society (2002). All Rights Reserved.		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3462.txt
	This document and translations of it may be copied and furnished to		The Multipart/Report Multipurpose Internet Mail Extensions (MIME)
	others, and derivative works that comment on or otherwise explain it		content-type is a general "family" or "container" type for electronic
	or assist in its implementation may be prepared, copied, published and		mail reports of any kind. Although this memo defines only the use of
	distributed, in whole or in part, without restriction of any kind,		the Multipart/Report content-type with respect to delivery status
	provided that the above copyright notice and this paragraph are		reports, mail processing programs will benefit if a single
	included on all such copies and derivative works. However, this		content-type is used to for all kinds of reports.
	document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of developing
	Internet standards in which case the procedures for copyrights defined
	in the Internet Standards process MUST be followed, or as required to
	translate it into languages other than English.
	The limited permissions granted above are perpetual and will not be		This document is part of a four document set describing the delivery
	revoked by the Internet Society or its successors or assigns.		status report service. This collection includes the Simple Mail
			Transfer Protocol (SMTP) extensions to request delivery status
			reports, a MIME content for the reporting of delivery reports, an
			enumeration of extended status codes, and a multipart container for
			the delivery report, the original message, and a human-friendly
			summary of the failure.
	This document and the information contained herein is provided on an		This is now a Proposed Standard Protocol.
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
	NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
	WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
	6. Author's Address		This document specifies an Internet standards track protocol for
			the Internet community, and requests discussion and suggestions
			for improvements. Please refer to the current edition of the
			"Internet Official Protocol Standards" (STD 1) for the
			standardization state and status of this protocol. Distribution
			of this memo is unlimited.
	Gregory M. Vaudreuil		This announcement is sent to the IETF list and the RFC-DIST list.
	Lucent Technologies		Requests to be added to or deleted from the IETF distribution list
	17080 Dallas Parkway		should be sent to IETF-REQUEST@IETF.ORG. Requests to be
	Dallas, TX 75248-1905		added to or deleted from the RFC-DIST distribution list should
	Voice/Fax: +1-972-733-2722		be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	GregV@ieee.org
	Appendix A - Changes from RFC1892		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
			an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
			help: ways_to_get_rfcs. For example:
	Changed Authors contact information		To: rfc-info@RFC-EDITOR.ORG
			Subject: getting rfcs
	Updated required standards boilerplate		help: ways_to_get_rfcs
	Edited the text to make it spell-checker and grammar checker compliant		Requests for special distribution should be addressed to either the
			author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
			specifically noted otherwise on the RFC itself, all RFCs are for
			unlimited distribution.echo
			Submissions for Requests for Comments should be sent to
			RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes. 14 change blocks.
	233 lines changed or deleted		44 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/