Browse Prior Art Database

The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages (RFC1892) Disclosure Number: IPCOM000004147D
Original Publication Date: 1996-Jan-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 5 page(s) / 7K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

G. Vaudreuil: AUTHOR


Status of this Memo

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 38% of the total text.

Network Working Group G. Vaudreuil

Request for Comments: 1892 Octel Network Services

Category: Standards Track January 1996

The Multipart/Report Content Type

for the Reporting of

Mail System Administrative Messages

Status of this Memo

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.

1. 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


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