Network Working Group B. Lilly Internet-Draft July 2005 Updates: 3462, 3464, 3798, 3886 (if approved) Expires: January 10, 2006 Extensible Message Application Interchange Language (EMAIL) -- Part Two: Syntax, Semantics, and Media Types draft-lilly-extensible-internet-message-format-p02-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The Internet Message Format originally formally specified in RFC 561 has been extended in some ways and for some purposes which have posed difficulties for some desirable operations such as digitally signed messages, have led to clutter in message content which in turn has led user agent implementers to suppress display of some originator message content, leading in some cases to user confusion, surprise, and embarrassment. This memo is part of a multi-document series that specifies an extensible message format which is intended to facilitate operations hampered by extensions to the current format and to reduce clutter in the user-to-user message content. This memo defines and provides registration information for media types relevant to the extensible message format. Lilly Expires January 10, 2006 [Page 1] Internet-Draft EMAIL Part 2: Syntax, Semantics, Media July 2005 Table of Contents 1. Introduction................................................... 3 2. Multipart/email................................................ 3 2.1. Semantics................................................. 3 2.2. Syntax.................................................... 3 2.3. Media Type Registration................................... 5 3. Message/email.................................................. 7 3.1. Semantics................................................. 7 3.2. Syntax.................................................... 7 3.3. Media Type Registration................................... 8 4. Security Considerations........................................ 9 5. Internationalization Considerations............................ 9 6. IANA Considerations............................................ 9 Appendix A. Disclaimers........................................... 9 Normative References.............................................. 10 Informative References............................................ 10 Author's Address.................................................. 11 Lilly Expires January 10, 2006 [Page 2] Internet-Draft EMAIL Part 2: Syntax, Semantics, Media July 2005 1. Introduction This memo will introduce two new media types which are used in the construction of an extensible message format. Semantics of each media type will be presented in prose, syntax will be presented in accompanying normative prose, incorporating keywords defined in [N1.BCP14], and media type registration data will be presented using the form specified in [I1.MediaReg]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHOULD", "SHOULD NOT" "RECOMMENDED" "MAY" and "OPTIONAL" in this document are to be interpreted as described in [N1.BCP14], 2. Multipart/email 2.1. Semantics The multipart/email media type denotes an extensible wrapper which contains a message, separate transport markings, and may contain ancillary information. It can be thought of as roughly equivalent to the "envelope" of a physical message. Unlike many physical envelopes, the multipart/email wrapper has separate compartments for the originator's message, routing and filing instructions, transport markings, classification schemes, etc. Also unlike most physical messages, the wrapper provides for multiple representations of originator content, providing a backward-compatible migration path which may be used to resolve limitations of RFC 561/680/724/733/822/2822 Internet message format [I2.RFC561], [I3.RFC680], [I4.RFC724], [I5.RFC733], [I6.STD11], [I7.RFC2822]. 2.2. Syntax The general syntax follows multipart media syntax as specified in section 5.1.1 of [N2.RFC2046]. There must be at least one body part, and exactly one body part MUST have type multipart/alternative. That multipart/alternative part MUST itself contain at least one body part and all body parts within that multipart/alternative part must have message type. An example of a simple case would have a single part of type message/rfc822. Each body part within the multipart/alternative part contains end-to-end, user-to-user content formatted according to the rules of the corresponding message type. As specified in [N2.RFC2046] section 5.1.4, order of parts within the multipart/alternative part is significant. Order of body parts within the multipart/email wrapper is not significant. Lilly Expires January 10, 2006 [Page 3] Internet-Draft EMAIL Part 2: Syntax, Semantics, Media July 2005 Aside from the required multipart/alternative composite media type containing the end-to-end message format(s), other media types enclosed in the multipart/email wrapper comprise ancillary data. It is RECOMMENDED that media types defined to hold ancillary data be defined as subtypes of the message top-level MIME type to permit both structured (as fields) and unstructured content. Some initial types will be proposed in a companion document [TBD]. The multipart/email wrapper SHOULD NOT directly contain a component of type message/rfc822; end-to-end message content is wrapped in the multipart/alternative component to provide extensibility. Using the notation given in [I8.Intro], the simple case example has the following structure: multipart/email 0 multipart/alternative 1 message/rfc822 1.1 text/plain 1.1.1 close delimiter 1 close delimiter 0 Note that the message/rfc822 part within the multipart/alternative part need not be a simple message; it MAY be a complex MIME message. An OpenPGP [I9.RFC3156] signed and encrypted message body with ancillary information generated by the originator's MUA could have the following structure: multipart/email 0 multipart/alternative 1 message/rfc822 1.1 multipart/encrypted 1.1.1 application/pgp-encrypted 1.1.1.1 application/octet-stream 1.1.1.2 close delimiter 1.1.1 close delimiter 1 message/omua 2 close delimiter 0 In the example above, the message body is encrypted, but the header is not. That may leave some information accessible to an eavesdropper. Alternatively, the encrypted content could include an entire message/rfc822 media type object, and the plaintext header could consist of placeholder fields. Note that details of the signing and encryption operations are not specified by this media type, and may have vulnerabilities. The media type provides a mechanism to isolate the end-to-end content from signature-breaking operations performed by transport agents; by itself the media type provides no guarantees of security or privacy for that content, nor can it protect against damage caused by non-compliant transport or transport-related agents. In particular, the layered aspect of signing and encryption used by some mechanisms leaves content open to vulnerabilities such as signature replacement, eavesdropping, and/or surreptitious forwarding. Lilly Expires January 10, 2006 [Page 4] Internet-Draft EMAIL Part 2: Syntax, Semantics, Media July 2005 2.3. Media Type Registration Type name: multipart Subtype name: email Required parameters: boundary: per [N2.RFC2046] section 5.1.1 version: An unsigned decimal integer number indicating the version of the media type specification. The value corresponding to this specification is 1. A version value change requires a new specification. A specification revision entailing any of the following means that a new version is REQUIRED: o addition of a mandatory part o specification such that existence or content of some part affects processing or display of the message as a whole or of any part other than the specific part whose existence or content is concerned A media type definition suitable as an optional part does not require a new version of multipart/email unless the second item above applies. Once a mandatory part is added to the specification (with a corresponding new version), that part MUST NOT subsequently be made optional. That prohibition is necessary to ensure backward compatibility of new versions. Consequently, addition of a mandatory part is a change that should not be made lightly. Optional parameters: none Encoding considerations: Encoding MUST be one of 7bit, 8bit, or binary per section 6.4 of [N3.RFC2045] and section 5.1 of [N2.RFC2046]. Encoding specified via a Content-Transfer-Encoding field MUST be consistent with enclosed media type domains and with the [N3.RFC2045] and [N2.RFC2046] requirements noted above. Restrictions on usage: none Security considerations: Making it easier for users and applications to find specific information necessarily makes it easier for attackers to find such information. Separating the end-to-end message information from transport markings facilitates digital signing and/or encryption of that communication, including header information, impeding eavesdropping and similar attacks. It facilitates Lilly Expires January 10, 2006 [Page 5] Internet-Draft EMAIL Part 2: Syntax, Semantics, Media July 2005 confidentiality, data integrity, and data origin authentication when used with message security mechanisms applied to the end-to-end message contained within the wrapper. This media type does not address security issues such as inappropriate usage and denial of service. Content could be moved from one wrapper to another, or unsigned content in the wrapper could be added, elided, or modified by an attacker. Specification of optional content formats SHOULD make provision for signing and/or encryption of that content if security or privacy are concerns. Interoperability considerations: Because the format of an EMAIL message is a MIME object, it can be handled by MIME-capable user agents, or by non-MIME-aware agents via an external package such as metamail [I10.Metamail]. Initially, many agents will not recognize the multipart/email type, and will treat it as multipart/mixed in accordance with [N2.RFC2046] section 5.1.3. That is reasonable, since the multipart/email type is in fact treated like multipart/mixed, but carries the semantics of a wrapped message and has specific message-related specifications. A wrapped message of type message/rfc822 contained within the multipart/alternative wrapper will be recognized (some existing UAs, tested prior to publication of the initial draft of this document, display the message inline, others may require that the MIME part be selected). Alternative new message subtypes, both for compartmentalizing ancillary data and for alternative end-to-end message content formatting which are unrecognized are treated as equivalent to application/octet-stream, per [N2.RFC2046] section 5.2.4. Some UAs in fact present that content inline, although that is non-conforming behavior [I11.RFC2049] (section 2, paragraph labeled "(4)"). These characteristics (appropriate handling of the wrapper, the embedded multipart/alternative, and the internal message/rfc822 message) are necessary and sufficient to meet the goal of backward compatibility for the purpose of end-to-end communications. Handling of ancillary information will progress at a rate dependent on the perceived need for such handling; likewise for development, deployment, and recognition of alternative message content formats (with message/rfc822 retained in the multipart/alternative wrapper for the foreseeable future as a fallback for legacy UAs). In the meantime, separation of such ancillary data and transport markings from the end-to-end message content enables end-to-end authentication of that message content without invalidation of digital signatures (because transport, including gateways, is prohibited from modifying the MIME-wrapped end-to-end message per [N2.RFC2046] section 5.2). That feature alone may be instrumental in reduction of the amount of messaging-based fraud which is rampant at the time of writing of this memo. Lilly Expires January 10, 2006 [Page 6] Internet-Draft EMAIL Part 2: Syntax, Semantics, Media July 2005 Published specification: This document. Applications which use this media type: Any applications using MIME and the Internet Message Format Additional information: Magic number(s): None File extension(s): Files do not require any specific "extension" or suffix. Many are in use as a convenience for mechanized processing of files. File names are orthogonal to the nature of the content. In particular, while a file name or a component of a name may be useful in some types of automated processing of files, the name or component might not be capable of indicating subtleties. This media type SHOULD NOT be assigned a relationship with any file "extension" where content may be untrusted unless there is provision for human judgment which may be used to override that relationship for individual files. Where appropriate, a filename MAY be suggested by a suitable mechanism such as the one specified in [I12.RFC2183] as amended by [I13.RFC2231] and . Macintosh File Type Code(s): unknown Person & email address to contact for further information: Bruce Lilly blilly@erols.com Intended usage: COMMON Author/Change controller: IESG 3. Message/email 3.1. Semantics The message/email media type holds a complete message consisting of a MIME-conforming message header and a body type containing a multipart/email composite media type. It is similar to message/rfc822 but has the added semantics of the extensible format. 3.2. Syntax Overall syntax is that of MIME message types and is similar to that of message/rfc822 with a composite MIME body. Note that due to optional extension parts, the content might require 8bit or binary transport. 3.2.1. Usage The message/email media type may be used in the same places as message/rfc822 provided there are no conflicts which would prevent such use. In particular, it may be used as an alternative to Lilly Expires January 10, 2006 [Page 7] Internet-Draft EMAIL Part 2: Syntax, Semantics, Media July 2005 message/rfc822 in a multipart/report media type [N4.RFC3462] as used by DSNs [I14.RFC3464], MDNs [I15.RFC3798], and MSTNs [I16.RFC3886]. For backward compatibility, a message/email media type which meets the syntax of message/rfc822 MAY be relabeled as message/rfc822 when used in a multipart/report composite media type. 3.3. Media Type Registration Type name: message Subtype name: email Required parameters: version: An unsigned decimal integer number indicating the version of the media type specification. The value corresponding to this specification is 1. Optional parameters: none Encoding considerations: Encoding MUST be one of 7bit, 8bit, or binary per section 6.4 of [N3.RFC2045] and section 5.1 of [N2.RFC2046] . Encoding specified via a Content-Transfer-Encoding field MUST be consistent with enclosed media type domains and with the [N3.RFC2045] and [N2.RFC2046] requirements noted above. Restrictions on usage: none Security considerations: As with any message media type, content can be forged or replaced via a man-in-the-middle. Security multiparts [I17.RFC1847] may be used to provide some protection. Interoperability considerations: This media type will be treated as application/octet-stream by MIME-conforming [I11.RFC2049] implementations which do not recognize the media subtype. In many cases, the content can be saved and treated as message/rfc822 with MIME content. Published specification: This document. Applications which use this media type: Any applications using MIME and the Internet Message Format Additional information: Magic number(s): None File extension(s): Files do not require any specific "extension" or suffix. Many are in use as a convenience for mechanized processing of files. File names are orthogonal to the nature of the content. In particular, while a file name or a component of a name may be useful in some types of automated processing of files, the name or component might not be capable of indicating subtleties. This media type SHOULD NOT be Lilly Expires January 10, 2006 [Page 8] Internet-Draft EMAIL Part 2: Syntax, Semantics, Media July 2005 assigned a relationship with any file "extension" where content may be untrusted unless there is provision for human judgment which may be used to override that relationship for individual files. Where appropriate, a filename MAY be suggested by a suitable mechanism such as the one specified in [I18.RFC2183] as amended by [I13.RFC2231] and . Macintosh File Type Code(s): unknown Person & email address to contact for further information: Bruce Lilly blilly@erols.com Intended usage: COMMON Author/Change controller: IESG 4. Security Considerations Security considerations relevant to media types are discussed in the media type registration form data in this memo. 5. Internationalization Considerations This memo raises no new internationalization considerations. It identifies some internationalization issues in general terms, and discusses an approach to those issues, also in general terms. 6. IANA Considerations Upon approval by the IESG, IANA SHALL register the media types defined in this document. Appendix A. Disclaimers This document has exactly one (1) author. In spite of the fact that the author's given name may also be the surname of other individuals, and the fact that the author's surname may also be a given name for some females, the author is, and has always been, male. The presence of "or she", "/SHE", "each", "their", and "authors" (plural) in the boilerplate sections of this document is irrelevant. As noted in the "Status of this Memo" section, this document is an Internet-Draft, and as such is a "work in progress", not a standard. Reference to this document's contents as "this standard" in the boilerplate are inappropriate. The author of this document is not responsible for the boilerplate text. Lilly Expires January 10, 2006 [Page 9] Internet-Draft EMAIL Part 2: Syntax, Semantics, Media July 2005 Comments regarding the silliness, lack of accuracy, and lack of precision of the boilerplate text should be directed to the IESG, not to the author. Normative References [N1.BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [N2.RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [N3.RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [N4.RFC3462] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003. Informative References [I1.MediaReg] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures" (draft-freed-media-type-reg-04.txt), April 2005. [I2.RFC561] Bhushan, A., Pogran, K., Tomlinson, R., and J. White, "Standardizing Network Mail Headers", RFC 561, September 1973. [I3.RFC680] Myer, T. and D. Henderson, "Message Transmission Protocol", RFC 680, April 1975. [I4.RFC724] Crocker, D., Pogran, K., Vittal, J., and D. Henderson, "Proposed official standard for the format of ARPA Network messages", RFC 724, May 1977. [I5.RFC733] Crocker, D., Vittal, J., Pogran, K., and D. Henderson, "Standard for the format of ARPA network text messages", RFC 733, November 1977. [I6.STD11] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. [I7.RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [I8.Intro] Lilly, B., "Extensible Message Application Interchange Language (EMAIL) -- Part One: Introduction and Overview", (draft-lilly-extensible-message-format-p1-00.txt), June 2005. Lilly Expires January 10, 2006 [Page 10] Internet-Draft EMAIL Part 2: Syntax, Semantics, Media July 2005 [I9.RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001. [I10.Metamail] http://guppylake.com/~nsb/metamail/mm2.7.tar.Z [I11.RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996. [I12.RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997. [I13.RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997. [I14.RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003. [I15.RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004. [I16.RFC3886] Allman, E., "An Extensible Message Format for Message Tracking Responses", RFC 3886, September 2004. [I17.RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995. [I18.RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997. Author's Address Bruce Lilly Email: blilly@erols.com Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS Lilly Expires January 10, 2006 [Page 11] Internet-Draft EMAIL Part 2: Syntax, Semantics, Media July 2005 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lilly Expires January 10, 2006 [Page 12]