Network Working Group                                 Greg Vaudreuil
       Internet Draft                                Octel Network Services
       Expires: 2/16/96                                        Aug 16, 1995
     
     
                        The Multipart/Report Content Type
                               for the Reporting of
                       Mail System Administrative Messages
     
                      <draft-ietf-notary-mime-report-05.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 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             Aug 16, 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 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) which 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 which 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, the message MUST be
       reencoded into 7 bits. If this is not possible (for example with
       non-MIME messages), the Text/RFC822-Headers content-type SHOULD be
       used to return the headers."
     
     
     
     
     
     
     
     
       Vaudreuil                   Expires 2/16/96                 [Page 2]


       Internet Draft             Multipart/Report             Aug 16, 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
       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, 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 2/16/96                 [Page 3]


       Internet Draft             Multipart/Report             Aug 16, 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
       Greg.Vaudreuil@Octel.com
       Voice/Fax: +1-214-733-2722
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
       Vaudreuil                   Expires 2/16/96                 [Page 4]