Individual Submission                                       M. Kucherawy
Internet-Draft                                                 Cloudmark
Obsoletes: 3462 (if approved)                           November 7, 2010
Intended status: Standards Track
Expires: May 11, 2011


    The Multipart/Report Media Type for the Reporting of Mail System
                        Administrative Messages
                     draft-kucherawy-rfc3462bis-00

Abstract

   The multipart/report Multipurpose Internet Mail Extensions (MIME)
   media 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 media type with respect to delivery status
   reports, mail processing programs will benefit if a single media type
   is used to for all kinds of reports.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents 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 "work in progress."

   This Internet-Draft will expire on May 11, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must



Kucherawy                 Expires May 11, 2011                  [Page 1]

Internet-Draft         Multipart/Report Media Type         November 2010


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Document Conventions . . . . . . . . . . . . . . . . . . . . .  4
   3.  The multipart/report Media Type  . . . . . . . . . . . . . . .  5
   4.  The text/rfc822-headers Media Type . . . . . . . . . . . . . .  7
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 11
   Appendix B.  Sample Reports  . . . . . . . . . . . . . . . . . . . 12
   Appendix C.  Document History  . . . . . . . . . . . . . . . . . . 13
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14































Kucherawy                 Expires May 11, 2011                  [Page 2]

Internet-Draft         Multipart/Report Media Type         November 2010


1.  Introduction

   [OLD-REPORT] and its antecedent declared the multipart/report media
   type for use within the [MIME] construct to create a container for
   mail system administrative reports of various kinds.

   Practical experience has shown that the requirement of having that
   media type constrained to be used only as the outermost MIME type of
   a message, while well-intentioned, has provided little operational
   benefit and actually limits such things as the transmission of
   multiple administrative reports within a single overall message
   container.

   This memo replaces that definition with one that is the same, minus
   that constraint.




































Kucherawy                 Expires May 11, 2011                  [Page 3]

Internet-Draft         Multipart/Report Media Type         November 2010


2.  Document Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, [KEYWORDS].














































Kucherawy                 Expires May 11, 2011                  [Page 4]

Internet-Draft         Multipart/Report Media Type         November 2010


3.  The multipart/report Media Type

   The multipart/report MIME media 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 media type
   with respect to delivery status reports, mail processing programs
   will benefit if a single media type is used to for all kinds of
   reports.

   Per [MIME-REG], the multipart/report media 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 6 of this memo

   The syntax of multipart/report is identical to the multipart/mixed
   content type defined in [MIME].  The report-type parameter identifies
   the type of report.  The parameter is the MIME sub-type of the second
   body part of the multipart/report.

   The multipart/report media type contains either two or three sub-
   parts, in the following order:

   1.  [REQUIRED] The first body part contains a 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 a 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 media 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 the second 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) that caused the report to be generated, along with



Kucherawy                 Expires May 11, 2011                  [Page 5]

Internet-Draft         Multipart/Report Media Type         November 2010


       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 could be useful to aid human
       experts in diagnosing problems.  (Although it might also be
       useful to allow the sender to identify the message about 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 that generated the delivery service
   report SHOULD return the full message content.

   When 8-bit or binary data not encoded in a 7-bit form is to be
   returned, and the return path is not guaranteed to be 8-bit or binary
   capable, two options are available.  The original message MAY be re-
   encoded into a legal 7-bit MIME message or the text/rfc822-headers
   media type MAY be used to return only the original message headers.

























Kucherawy                 Expires May 11, 2011                  [Page 6]

Internet-Draft         Multipart/Report Media Type         November 2010


4.  The text/rfc822-headers Media Type

   The text/rfc822-headers media type provides a mechanism to label and
   return only the [MAIL] header of a failed message.  The header is not
   the complete message and SHOULD NOT be returned using the message/
   rfc822 media type defined in [MIME-TYPES].  The returned header is
   useful for identifying the failed message and for diagnostics based
   on the Received header fields.

   The text/rfc822-headers media 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 mail
      headers, however, if the headers are broken and require encoding
      to make them legal 7-bit content, they may be encoded with quoted-
      printable as defined in [MIME]

   Security considerations:  See Section 6 of this memo.

   The text/rfc822-headers body part SHOULD contain all the mail header
   fields from the message that caused the report.  The header includes
   all header fields prior to the first blank line in the message.  They
   include the MIME-Version and MIME content description fields.





















Kucherawy                 Expires May 11, 2011                  [Page 7]

Internet-Draft         Multipart/Report Media Type         November 2010


5.  IANA Considerations

   IANA is directed to update the Media Type Registry to indicate that
   this memo contains the current definition of the multipart/report and
   text/rfc822-headers media types, obsoleting [OLD-REPORT].














































Kucherawy                 Expires May 11, 2011                  [Page 8]

Internet-Draft         Multipart/Report Media Type         November 2010


6.  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.

   A signature covering the entire multipart/report structure could be
   used to prevent such forgeries; such a signature scheme is, however,
   beyond the scope of this document.







































Kucherawy                 Expires May 11, 2011                  [Page 9]

Internet-Draft         Multipart/Report Media Type         November 2010


7.  References

7.1.  Normative References

   [KEYWORDS]
              Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, March 1997.

   [MAIL]     Resnick, P., "Internet Message Format", RFC 5322,
              October 2008.

   [MIME]     Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [MIME-REG]
              Freed, N. and J. Klensin, "Media Type Specifications and
              Registration Procedures", RFC 4288, December 2005.

   [MIME-TYPES]
              Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Two: Media Types", RFC 2046,
              November 1996.

   [OLD-REPORT]
              Vaudreuil, G., "The Multipart/Report Content Type for the
              Reporting of Mail System Administrative Messages",
              RFC 3462, January 2003.

7.2.  Informative References

   [DRPT]     Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
              Extension for Delivery Status Notifications (DSNs)",
              RFC 3461, January 2003.

   [DSN]      Moore, K. and G. Vaudreuil, "An Extensible Message Format
              for Delivery Status Notifications", RFC 3464,
              January 2003.













Kucherawy                 Expires May 11, 2011                 [Page 10]

Internet-Draft         Multipart/Report Media Type         November 2010


Appendix A.  Acknowledgements

   The author would like to thank (blah).
















































Kucherawy                 Expires May 11, 2011                 [Page 11]

Internet-Draft         Multipart/Report Media Type         November 2010


Appendix B.  Sample Reports

   A sample report or two should go here.
















































Kucherawy                 Expires May 11, 2011                 [Page 12]

Internet-Draft         Multipart/Report Media Type         November 2010


Appendix C.  Document History

   Changes from RFC3462 to draft-kucherawy-rfc3462bis-00:

   o  Remove requirement that multipart/report not be contained in
      anything.

   o  Some minor adjustment to use current terminology, such as
      distinguishing between a header and a header field.

   o  More obvious use of the standard normative words.








































Kucherawy                 Expires May 11, 2011                 [Page 13]

Internet-Draft         Multipart/Report Media Type         November 2010


Author's Address

   Murray S. Kucherawy
   Cloudmark
   128 King St., 2nd Floor
   San Francisco, CA  94107
   US

   Phone: +1 415 946 3800
   Email: msk@cloudmark.com









































Kucherawy                 Expires May 11, 2011                 [Page 14]