Network Working Group                                 Greg Vaudreuil
       Internet Draft                                Octel Network Services
       Expires: 11/5/95                                         May 5, 1995
                        The Multipart/Report Content Type
                               for the Reporting of
                       Mail System Administrative Messages
     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
       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 5 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              May 5, 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
          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 11/5/95                 [Page 2]

       Internet Draft             Multipart/Report              May 5, 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 Message/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 5 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 11/5/95                 [Page 3]

       Internet Draft             Multipart/Report              May 5, 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 1521, 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
       Voice/Fax: +1-214-733-2722
       Vaudreuil                   Expires 11/5/95                 [Page 4]