Individual Submission M. Kucherawy, Ed.
Internet-Draft Cloudmark
Obsoletes: 3462 (if approved) October 18, 2011
Intended status: Standards Track
Expires: April 20, 2012
The Multipart/Report Media Type for the Reporting of Mail System
Administrative Messages
draft-ietf-appsawg-rfc3462bis-02
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 for all kinds of reports.
This memo obsoletes RFC3462. The IESG is also requested to mark
RFC1892 and RFC3462 as "historic".
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 April 20, 2012.
Copyright Notice
Copyright (c) 2011 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
Kucherawy Expires April 20, 2012 [Page 1]
Internet-Draft Multipart/Report Media Type October 2011
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
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 . . . . . . . . . . . . . . 8
5. Registering New Report Types . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14
Appendix B. Document History . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Kucherawy Expires April 20, 2012 [Page 2]
Internet-Draft Multipart/Report Media Type October 2011
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 general requirement of having
that media type constrained to be used only as the outermost MIME
type of a message is overly and limits such things as the
transmission of multiple administrative reports within a single
overall message container. In particular, it prevents one from
forwarding a report as part of another multipart MIME message.
This memo removes that constraint. No other changes apart from some
editorial ones are made. Other memos might update other documents to
establish or clarify the constraints on use of multipart/report in
contexts where such are needed.
This memo obsoletes RFC3462. The IESG is also requested to mark
RFC1892 and RFC3462 as "historic".
Kucherawy Expires April 20, 2012 [Page 3]
Internet-Draft Multipart/Report Media Type October 2011
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 [KEYWORDS].
Kucherawy Expires April 20, 2012 [Page 4]
Internet-Draft Multipart/Report Media Type October 2011
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 for all kinds of reports.
Per [MIME-REG], the multipart/report media type is defined as
follows:
Type name: multipart
Subtype name: report
Required parameters: boundary, report-type
Optional parameters: none
Encoding considerations: 7bit should always be adequate
Security considerations: see Section 7 of [this memo]
Interoperability considerations: see Section 1 of [this memo]
Published specification: [this memo]
Applications that use this media type: Mail Transfer Agents, Mail
User Agents, spam detection and reporting modules, virus detection
modules, message authentication modules
Additional information:
Magic number(s): N/A
File extensions(s): N/A
Macintosh file type code(s): N/A
Person and email address to contact for further information: Murray
S. Kucherawy <msk@cloudmark.com>
Intended usage: common
Restrictions on usage: none; however, other applications that
register report types may establish such restrictions
Kucherawy Expires April 20, 2012 [Page 5]
Internet-Draft Multipart/Report Media Type October 2011
Author: Murray S. Kucherawy <msk@cloudmark.com>
Change controller: IESG
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. (See Section 5.)
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 might not have a user agent
capable of interpreting the second section of the multipart/
report. The text in the first section can use any IANA-
registered MIME 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
details not present in the first body part that might be useful
to human experts. An initial body part, message/delivery-status
is defined in [DSN-FORMAT].
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 can be wasteful of network bandwidth and a variety
of implementation strategies can be used. Generally the sender needs
to 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 [DSN-SMTP], the agent that generated the delivery service report
SHOULD return the full message content.
Kucherawy Expires April 20, 2012 [Page 6]
Internet-Draft Multipart/Report Media Type October 2011
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 April 20, 2012 [Page 7]
Internet-Draft Multipart/Report Media Type October 2011
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:
Type name: text
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 or extended 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 7 of [this memo].
Interoperability considerations: none
Published specification: [this memo]
Applications that use this media type: Mail Transfer Agents, Mail
User Agents, spam detection and reporting modules, virus detection
modules, message authentication modules
Additional information:
Magic number(s): N/A
File extensions(s): N/A
Macintosh file type code(s): N/A
Person and email address to contact for further information: Murray
S. Kucherawy <msk@cloudmark.com>
Kucherawy Expires April 20, 2012 [Page 8]
Internet-Draft Multipart/Report Media Type October 2011
Intended usage: common
Restrictions on usage: none
Author: Murray S. Kucherawy <msk@cloudmark.com>
Change controller: IESG
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 April 20, 2012 [Page 9]
Internet-Draft Multipart/Report Media Type October 2011
5. Registering New Report Types
Registration of new media types for the purpose of creating a new
report format SHOULD note in the Intended Usage section of the media
type registration that the type being registered is suitable for use
as a report-type (i.e., the second body part) in the context of this
specification.
Kucherawy Expires April 20, 2012 [Page 10]
Internet-Draft Multipart/Report Media Type October 2011
6. 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 April 20, 2012 [Page 11]
Internet-Draft Multipart/Report Media Type October 2011
7. 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 can 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 April 20, 2012 [Page 12]
Internet-Draft Multipart/Report Media Type October 2011
8. References
8.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.
8.2. Informative References
[DSN-FORMAT]
Moore, K. and G. Vaudreuil, "An Extensible Message Format
for Delivery Status Notifications", RFC 3464,
January 2003.
[DSN-SMTP]
Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications (DSNs)",
RFC 3461, January 2003.
[OLD-REPORT]
Vaudreuil, G., "The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages",
RFC 3462, January 2003.
Kucherawy Expires April 20, 2012 [Page 13]
Internet-Draft Multipart/Report Media Type October 2011
Appendix A. Acknowledgements
The author would like to thank Dave Crocker, Frank Ellermann, Ned
Freed, Randall Gellens, Alexey Melnikov and Keith Moore for their
input to this update.
Thanks also go to Gregory M. Vaudreuil, the original creator of this
media type.
Kucherawy Expires April 20, 2012 [Page 14]
Internet-Draft Multipart/Report Media Type October 2011
Appendix B. Document History
[RFC Editor: Please remove this section prior to publication.]
Changes from draft-ietf-appsawg-rfc3462bis-01 to
draft-ietf-appsawg-rfc3462bis-02:
o Minor copy editing based on WGLC feedback.
o Make OLD-REPORT into an informative reference.
o Update media type registration templates.
Changes from draft-ietf-appsawg-rfc3462bis-00 to
draft-ietf-appsawg-rfc3462bis-01:
o Minor copy editing based on WG feedback.
Changes from draft-kucherawy-rfc3462bis-02 to
draft-ietf-appsawg-rfc3462bis-00:
o Renamed.
Changes from draft-kucherawy-rfc3462bis-01 to
draft-kucherawy-rfc3462bis-02:
o Revert to removing the restriction altogether, noting that the DSN
and MDN RFCs re-state it. Thus, removing it here solves MARF's
problem but doesn't impact DSN and MDN. The restriction can be
clarified on those documents in separate efforts.
Changes from draft-kucherawy-rfc3462bis-00 to
draft-kucherawy-rfc3462bis-01:
o Clarify requirement that multipart/report must be the outermost
media type; require it only when generating a report.
o Highlight the forwarding-of-reports problem.
o Limit the constraint to time of report generation.
o Remove "Examples" section.
Changes from RFC3462 to draft-kucherawy-rfc3462bis-00:
o Remove requirement that multipart/report not be contained in
anything.
Kucherawy Expires April 20, 2012 [Page 15]
Internet-Draft Multipart/Report Media Type October 2011
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 April 20, 2012 [Page 16]
Internet-Draft Multipart/Report Media Type October 2011
Author's Address
Murray S. Kucherawy (editor)
Cloudmark
128 King St., 2nd Floor
San Francisco, CA 94107
US
Phone: +1 415 946 3800
Email: msk@cloudmark.com
Kucherawy Expires April 20, 2012 [Page 17]
