RFC 1892 (rfc1892) - Page 3 of 4

The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages

Alternative Format: Original Text Document
< Previous
Next >
RFC 1892                    Multipart/Report                January 1996


2. The Text/RFC 822-Headers MIME content-type

   The Text/RFC 822-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/RFC 822.  The returned headers are useful for identifying the
   failed message and for diagnostics based on the received: lines.

   The Text/RFC 822-Headers content-type is defined as follows:

          MIME type name: Text
          MIME subtype name: RFC 822-Headers
          Required parameters: None
          Optional parameters: none
          Encoding considerations: 7 bit is sufficient for normal RFC 822
                 headers, however, if the headers are broken and require
                 encoding, they may be encoded in quoted-printable.
          Security considerations: see section 4 of this memo.

   The Text/RFC 822-headers body part should contain all the RFC 822
   header lines from the message which caused the report.  The RFC 822
   headers include all lines prior to the blank line in the message.
   They include the MIME-Version and MIME Content- headers.

3. References

   [DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
       Delivery Status Notifications", RFC 1894, University of
       Tennessee, Octel Network Services, January 1996.

   [RFC 822] Crocker, D., "Standard for the format of ARPA Internet Text
       Messages", STD 11, RFC 822, UDEL, August 1982.

   [MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
       Extensions", RFC 1521, Bellcore, Innosoft, June 1992.

   [DRPT] Moore, K., "SMTP Service Extension for Delivery Status
       Notifications", RFC 1891, University of Tennessee, January 1996.

4. Security Considerations

   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.




Vaudreuil                   Standards Track
< Previous
Next >