HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 05:58:33 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Wed, 18 Jan 1995 23:00:00 GMT ETag: "361b10-1c51-2f1d9d70" Accept-Ranges: bytes Content-Length: 7249 Connection: close Content-Type: text/plain Network Working Group Greg Vaudreuil Internet Draft Octel Network Services Expires: July 16, 1995 January 16, 1995 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages Changes since last revision: 1) Multipart/Report is required to be the outermost MIME content-type to facilitate automatic detection and processing by a UA via RFC 822 header parsing. 2) The third section of the multipart may be any labeled MIME content-type necessary to return the content of the message. 3) A new mime content type is defined for the return of the headers only in the third body part. While headers are a subset of the Message/RFC822 content-type, the semantics are different. 1. Status of this Memo 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". 2. The multipart/report MIME 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. Internet Draft Multipart/Report 1/16/95 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 7 of this memo. The syntax of multipart/Report is identical to the Multipart/Mixed content type defined in [3]. When used to send a report, the multipart/report content-type must be the top-level MIME content type for any report message. A 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 is a text/plain body part containing explanatory text. This text may be in any MIME standards-track charset, and in any language. The purpose of this text is to provide, for a human reader who may not have an user agent capable of interpreting a message/report, an easily-understood description of the condition(s) that caused the report to be generated. This body part may also be used to send detailed trace information that cannot be easily formatted into a message/report body part. (2) [required] A message/report 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) which caused the report to be generated, along with details not present in the text/plain body part that may be useful to human experts. (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.) The Message/Report body part contains the specific service report information, such as error reports, read-receipts, and service reports. This content-type is defined in [1]. 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 Vaudreuil Expires July 16, 1995 [Page 2] Internet Draft Multipart/Report 1/16/95 returned content required. In the absence of an explicit request for level of return of content such as that provided in [5], the agent which generated the delivery service report should return the full message content. The Message/RFC822-Headers MIME content-type 3. The Message/RFC822-Headers MIME content-type provides a mechanism to label and return only the 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 correlating the erred message and for diagnostics based on the received-from: lines. The Message/RFC822-Headers content-type is defined as follows: MIME type name: Message MIME subtype name: RFC822-Headers Required parameters: None Optional parameters: none Encoding considerations: 7 bit is sufficient Security considerations: see section 7 of this memo. The message/RFC822-headers body part must contain all the RFC822 header lines from the message which caused the report. References 4. [1] Moore, K., Vaudreuil, G., "An Extensible Message Format for Delivery Status Reports", Internet-Draft. [2] Crocker, D., "Standard for the format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982. [3 Borenstein, N., Freed, N., "Multipurpose Internet Mail Extensions", RFC 1341, Bellcore, Innosoft, June 1992. Security Consideration 5. Multipart/Report introduces no security threats beyond those already present in Internet mail. Automated use of report types without authentication may increase the opportunities for denial-of-service attacks. 6. Author's Address Gregory M. Vaudreuil Octel Network Services 17060 Dallas Parkway Dallas, TX 75248-1905 Greg.Vaudreuil@ONS.Octel.com Vaudreuil Expires July 16, 1995 [Page ] 3