RFC 2046 Draft Standard Message format

Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types

This second document defines the general structure of the MIME media typing system and defines an initial set of media types. [STANDARDS-TRACK]

Status
Draft Standard. A maturity level the IETF retired in 2011. Documents that had reached it kept the label, so it still appears on current work such as RFC 5321.
Published
November 1996
Authors
N. Freed, N. Borenstein
Read it
rfc-editor.org · errata · DOI

Replaces RFC 1341: MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies, RFC 1342: Representation of Non-ASCII Text in Internet Message Headers, RFC 1521: MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies, RFC 1522: MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text, RFC 1590: Media Type Registration Procedure.

This document is current and has been amended. 5 later RFCs have changed part of it. Nothing on the RFC itself tells you this.

Normative requirements

Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 10 must, 1 should, 0 may.

4.1.1 Representation of Line Breaks

  • MUSTThe canonical form of any MIME "text" subtype MUST always represent a line break as a CRLF sequence.
  • MUSTSimilarly, any occurrence of CRLF in MIME "text" MUST represent a line break.

4.1.2 Charset Parameter

  • MUSTmessages containing characters coded according to other versions of ISO 646 than US-ASCII and the 1991 IRV, or using code-switching procedures (e.g., those of ISO 2022), as well as 8bit or multiple octet character encodings MUST use an appropriate character set specification to be consistent with MIME.
  • SHOULDFor example, if a body contains only US-ASCII characters, it SHOULD be marked as being in the US- ASCII character set, not ISO-8859-1, which, like all the ISO-8859 family of character sets, is a superset of US-ASCII.

5.1 Multipart Media Type

  • MUST NOTThe boundary delimiter MUST NOT appear inside any of the encapsulated parts, on a line by itself or as the prefix of any line.

5.1.1 Common Syntax

  • MUSTThe boundary delimiter MUST occur at the beginning of a line, i.e., following a CRLF, and the initial CRLF is considered to be attached to the boundary delimiter line rather than part of the preceding part.
  • MUST NOTtransport-padding := *LWSP-char ; Composers MUST NOT generate ; non-zero length transport ; padding, but receivers MUST ; be able to handle padding ; added by message transports.

5.2.2 Partial Subtype

  • MUSTBut the third piece MUST specify the total number of fragments:

5.2.3 External-Body Subtype

  • MUSTThe encapsulated headers in ALL "message/external-body" entities MUST include a Content-ID header field to give a unique identifier by which to reference the data.
  • MUSTAs with "message/partial", MIME entities of type "message/external- body" MUST have a content-transfer-encoding of 7bit (the default).

5.2.3.1 General External-Body Parameters

  • MUSTThis parameter is unconditionally mandatory and MUST be present on EVERY "message/external-body".

Every current email RFC