Network Working Group Greg Vaudreuil
Internet Draft Octel Network Services
Expires: October 20, 1995 April 20, 1995
The Multipart/Report Content Type
for the Reporting of
Mail System Administrative Messages
<draft-ietf-notary-mime-report-02.txt>
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.
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 [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.
Internet Draft Multipart/Report April 20, 1995
The Multipart/Report content-type contains either two or three sub-
parts, in the following order:
(1) [required] The first body part contains human consumable
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 text 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 trace
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) 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. 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 which generated the delivery service
report should return the full message content.
Vaudreuil Expires October 20, 1995 [Page 2]
Internet Draft Multipart/Report April 20, 1995
3. The Text/RFC822-Headers MIME 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 Text/RFC822. The returned headers are useful for
correlating the erred message and for diagnostics based on the
received: lines.
The Text/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 for normal RFC822
headers, however, if the headers are broken and require
encoding, they may be encoded in quoted-printable.
Security considerations: see section 7 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.
Vaudreuil Expires October 20, 1995 [Page 3]
Internet Draft Multipart/Report April 20, 1995
4. References
[DSN] Moore, K., Vaudreuil, G., "An Extensible Message Format for
Delivery Status Reports", Internet-Draft.
[RFC822] Crocker, D., "Standard for the format of ARPA Internet Text
Messages", STD 11, RFC 822, UDEL, August 1982.
[MIME] Borenstein, N., Freed, N., "Multipurpose Internet Mail
Extensions", RFC 1341, Bellcore, Innosoft, June 1992.
[DRPT] Moore, K., "SMTP Service Extension for Delivery Status
Notifications", Internet Draft.
5. Security Consideration
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.
6. Author's Address
Gregory M. Vaudreuil
Octel Network Services
17060 Dallas Parkway
Dallas, TX 75248-1905
Greg.Vaudreuil@Octel.com
Voice/Fax: +1-214-733-2722
Vaudreuil Expires October 20, 1995 [Page 4]
