home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1800s / rfc1892.txt < prev    next >
Text File  |  1996-01-09  |  8KB  |  228 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       G. Vaudreuil
  8. Request for Comments: 1892                        Octel Network Services
  9. Category: Standards Track                                   January 1996
  10.  
  11.  
  12.                    The Multipart/Report Content Type
  13.                           for the Reporting of
  14.                   Mail System Administrative Messages
  15.  
  16. Status of this Memo
  17.  
  18.    This document specifies an Internet standards track protocol for the
  19.    Internet community, and requests discussion and suggestions for
  20.    improvements.  Please refer to the current edition of the "Internet
  21.    Official Protocol Standards" (STD 1) for the standardization state
  22.    and status of this protocol.  Distribution of this memo is unlimited.
  23.  
  24. 1. The Multipart/Report MIME content-type
  25.  
  26.    The Multipart/Report MIME content-type is a general "family" or
  27.    "container" type for electronic mail reports of any kind. Although
  28.    this memo defines only the use of the Multipart/Report content-type
  29.    with respect to delivery status reports, mail processing programs
  30.    will benefit if a single content-type is used to for all kinds of
  31.    reports.
  32.  
  33.    The Multipart/Report content-type is defined as follows:
  34.  
  35.              MIME type name: multipart
  36.              MIME subtype name: report
  37.              Required parameters: boundary, report-type
  38.              Optional parameters: none
  39.              Encoding considerations: 7bit should always be adequate
  40.              Security considerations: see section 4 of this memo.
  41.  
  42.    The syntax of Multipart/Report is identical to the Multipart/Mixed
  43.    content type defined in [MIME].  When used to send a report, the
  44.    Multipart/Report content-type must be the top-level MIME content type
  45.    for any report message.  The report-type parameter identifies the
  46.    type of report.  The parameter is the MIME content sub-type of the
  47.    second body part of the Multipart/Report.
  48.  
  49.       User agents and gateways must be able to automatically determine
  50.       that a message is a mail system report and should be processed as
  51.       such.  Placing the Multipart/Report as the outermost content
  52.       provides a mechanism whereby an auto-processor may detect through
  53.       parsing the RFC 822 headers that the message is a report.
  54.  
  55.  
  56.  
  57.  
  58. Vaudreuil                   Standards Track                     [Page 1]
  59.  
  60. RFC 1892                    Multipart/Report                January 1996
  61.  
  62.  
  63.    The Multipart/Report content-type contains either two or three sub-
  64.    parts, in the following order:
  65.  
  66.    (1) [required]  The first body part contains human readable message.
  67.        The purpose of this message is to provide an easily-understood
  68.        description of the condition(s) that caused the report to be
  69.        generated, for a human reader who may not have an user agent
  70.        capable of interpreting the second section of the
  71.        Multipart/Report.
  72.  
  73.        The text in the first section may be in any MIME standards-track
  74.        content-type, charset, or language.  Where a description of the
  75.        error is desired in several languages or several media, a
  76.        Multipart/Alternative construct may be used.
  77.  
  78.        This body part may also be used to send detailed information
  79.        that cannot be easily formatted into a Message/Report body part.
  80.  
  81.    (2) [required]  A machine parsable body part containing an account
  82.        of the reported message handling event. The purpose of this body
  83.        part is to provide a machine-readable description of the
  84.        condition(s) which caused the report to be generated, along with
  85.        details not present in the first body part that may be useful to
  86.        human experts.  An initial body part, Message/delivery-status is
  87.        defined in [DSN]
  88.  
  89.    (3) [optional]  A body part containing the returned message or a
  90.        portion thereof.  This information may be useful to aid human
  91.        experts in diagnosing problems.  (Although it may also be useful
  92.        to allow the sender to identify the message which the report was
  93.        issued, it is hoped that the envelope-id and original-recipient-
  94.        address returned in the Message/Report body part will replace
  95.        the traditional use of the returned content for this purpose.)
  96.  
  97.    Return of content may be wasteful of network bandwidth and a variety
  98.    of implementation strategies can be used.  Generally the sender
  99.    should choose the appropriate strategy and inform the recipient of
  100.    the required level of returned content required.  In the absence of
  101.    an explicit request for level of return of content such as that
  102.    provided in [DRPT], the agent which generated the delivery service
  103.    report should return the full message content.
  104.  
  105.    When data not encoded in 7 bits is to be returned, and the return
  106.    path is not guaranteed to be 8-bit capable, two options are
  107.    available.  The origional message MAY be reencoded into a legal 7 bit
  108.    MIME message or the Text/RFC822-Headers content-type MAY be used to
  109.    return only the origional message headers.
  110.  
  111.  
  112.  
  113.  
  114. Vaudreuil                   Standards Track                     [Page 2]
  115.  
  116. RFC 1892                    Multipart/Report                January 1996
  117.  
  118.  
  119. 2. The Text/RFC822-Headers MIME content-type
  120.  
  121.    The Text/RFC822-Headers MIME content-type provides a mechanism to
  122.    label and return only the RFC 822 headers of a failed message.  These
  123.    headers are not the complete message and should not be returned as a
  124.    Message/RFC822.  The returned headers are useful for identifying the
  125.    failed message and for diagnostics based on the received: lines.
  126.  
  127.    The Text/RFC822-Headers content-type is defined as follows:
  128.  
  129.           MIME type name: Text
  130.           MIME subtype name: RFC822-Headers
  131.           Required parameters: None
  132.           Optional parameters: none
  133.           Encoding considerations: 7 bit is sufficient for normal RFC822
  134.                  headers, however, if the headers are broken and require
  135.                  encoding, they may be encoded in quoted-printable.
  136.           Security considerations: see section 4 of this memo.
  137.  
  138.    The Text/RFC822-headers body part should contain all the RFC822
  139.    header lines from the message which caused the report.  The RFC822
  140.    headers include all lines prior to the blank line in the message.
  141.    They include the MIME-Version and MIME Content- headers.
  142.  
  143. 3. References
  144.  
  145.    [DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
  146.        Delivery Status Notifications", RFC 1894, University of
  147.        Tennessee, Octel Network Services, January 1996.
  148.  
  149.    [RFC822] Crocker, D., "Standard for the format of ARPA Internet Text
  150.        Messages", STD 11, RFC 822, UDEL, August 1982.
  151.  
  152.    [MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
  153.        Extensions", RFC 1521, Bellcore, Innosoft, June 1992.
  154.  
  155.    [DRPT] Moore, K., "SMTP Service Extension for Delivery Status
  156.        Notifications", RFC 1891, University of Tennessee, January 1996.
  157.  
  158. 4. Security Considerations
  159.  
  160.    Automated use of report types without authentication presents several
  161.    security issues.  Forging negative reports presents the opportunity
  162.    for denial-of-service attacks when the reports are used for automated
  163.    maintenance of directories or mailing lists.  Forging positive
  164.    reports may cause the sender to incorrectly believe a message was
  165.    delivered when it was not.
  166.  
  167.  
  168.  
  169.  
  170. Vaudreuil                   Standards Track                     [Page 3]
  171.  
  172. RFC 1892                    Multipart/Report                January 1996
  173.  
  174.  
  175. 5. Author's Address
  176.  
  177.    Gregory M. Vaudreuil
  178.    Octel Network Services
  179.    17060 Dallas Parkway
  180.    Dallas, TX 75248-1905
  181.  
  182.    Phone: +1-214-733-2722
  183.    EMail: Greg.Vaudreuil@Octel.com
  184.  
  185.  
  186.  
  187.  
  188.  
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Vaudreuil                   Standards Track                     [Page 4]
  227.  
  228.