MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies
obsoleted by
- rfc-2045 — Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
- rfc-2046 — Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
- rfc-2047 — MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text
- rfc-2048 — Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures
- rfc-2049 — Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples
obsoletes
- rfc-1341 — MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies
updated by
- rfc-1590 — Media Type Registration Procedure
Extracted elements (31)
Compatibility was always favored over elegance in MIME design. Several mechanisms may seem baroque at first reading, but the working group prioritized compatibility with existing RFC 822 standards and robustness across existing practice above all else.
Content-Transfer-Encoding is deliberately decoupled from Content-Type to avoid coupling transport requirements with content format definitions. Different transports have different capabilities (7-bit SMTP vs. 8-bit), and the same Content-Type may appropriately use different encodings in different contexts.
Nested content-transfer-encodings are prohibited for multipart and message types to prevent data being passed through encoding algorithms multiple times. Such nesting would obscure message structure, require multiple decoding passes just to identify content types, and introduce efficiency problems.
The multipart boundary mechanism uses '--' prefix for rough RFC 934 compatibility, but is intentionally NOT fully RFC 934 compatible. RFC 934's quoting convention was rejected because it causes lines to grow with each nesting level, which combined with SMTP line-length limits made it unsuitable for deeply-nested multipart structures.
MIME is designed to be largely orthogonal to RFC 822 rather than a revision of it. RFC 822 messages without MIME-Version or Content-Type headers must be treated as 'text/plain; charset=us-ascii', but such messages may in practice contain almost anything, including uuencoded binary data.
Quoted-Printable encoding may not work correctly through EBCDIC gateways. For higher reliability through such gateways, additional ASCII characters (including !, ", #, $, @, [, \, ], ^, `, {, |, }, ~) should also be encoded per Rule 1. Base64 is preferred for binary data and provides higher transport reliability.
A subtype specification in Content-Type is MANDATORY — there are no default subtypes. New top-level content types may only be defined by an extension to the standard; experimental or private types must begin with 'X-'.
All multipart subtypes MUST use the identical multipart syntax. Any unrecognized multipart subtype must be treated as multipart/mixed, ensuring that all conformant user agents can at least recognize and separate the parts of any multipart entity.
Entities of type 'multipart' or 'message' MUST NOT use Content-Transfer-Encoding values other than '7bit', '8bit', or 'binary'. All encoding of inner content must be applied at the innermost level, by encoding the actual body that needs encoding.
In Quoted-Printable, uppercase letters MUST be used when sending hexadecimal data. When decoding, any trailing white space on a line MUST be deleted, as it will necessarily have been added by intermediate transport agents.
Mail-sending software must always use the lowest common denominator character set. If a body contains only US-ASCII characters, it MUST be labeled US-ASCII, not a superset like ISO-8859-1. National variations of ISO 646 are NOT ASCII and their use in Internet mail is explicitly discouraged.
Messages composed in accordance with MIME MUST include a MIME-Version header field with the verbatim value '1.0'. The presence of this field asserts that the message complies with the MIME specification; its absence means MIME conformance cannot be assumed.
The encapsulation boundary MUST NOT appear inside any encapsulated body part. Boundaries must be no longer than 70 characters (not counting the two leading hyphens). Mail handling agents are explicitly forbidden from adding, removing, or reordering body-part headers embedded within multipart message bodies.
When a mail reader encounters an unknown Content-Type value, it should treat it as equivalent to 'application/octet-stream'. If no Content-Type header is present, 'text/plain; charset=us-ascii' is assumed as the default.
Application/Octet-Stream is the primary subtype for uninterpreted binary data; the simplest recommended action on receipt is to offer to write the data to a file. Application/PostScript is defined for transporting PostScript documents but carries significant security concerns due to PostScript's programmability.
Message/External-Body references large body content stored externally, using an 'access-type' parameter. Defined access types are 'ftp', 'tftp', 'anon-ftp', 'local-file', 'afs', and 'mail-server'. A Content-ID header is mandatory for all message/external-body entities to enable caching.
Message/Partial enables fragmented transmission of large messages. Required parameters are 'id' (globally-unique shared identifier), 'number' (1-based fragment sequence number), and 'total' (total fragment count, required only in the last fragment). Reassembly is performed by concatenating fragments in order.
Multipart/alternative contains multiple representations of the same information ordered from least to most preferred. A receiving system should display the best version it can handle, chosen based on local environment and preferences. All parts share the same Content-ID when representing the same data.
Multipart/digest is a subtype where each body part defaults to Content-Type 'message/rfc822' rather than 'text/plain', making it suitable for transmitting collections of messages such as mailing list digests.
The 'charset' parameter for text Content-Types specifies the character set of the body. The default is US-ASCII. Defined values at publication are US-ASCII and ISO-8859-1 through ISO-8859-9. The parameter value is NOT case-sensitive. New character set names require IANA registration.
The Content-Description header field (syntax: 'description := "Content-Description" ":" *text') associates human-readable descriptive text with a body part. The value is presumed US-ASCII unless encoded per RFC 1522.
The Content-ID header field (syntax: 'id := "Content-ID" ":" msg-id') provides a world-unique identifier for a MIME entity. It is mandatory for message/external-body entities to enable caching, and carries special semantics within multipart/alternative.
The Content-Transfer-Encoding header field specifies the encoding applied to the body for transport. Defined mechanisms are: 7bit, quoted-printable, base64, 8bit, binary, and x-token (non-standard). The default is 7bit when the field is absent. New encoding values are explicitly and strongly discouraged.
The Content-Type header field specifies the type and subtype of the body using the syntax 'content := "Content-Type" ":" type "/" subtype *(";"; parameter)'. Seven top-level types are defined: text, multipart, message, image, audio, video, and application. Type, subtype, and parameter names are case-insensitive; parameter values are case-sensitive unless otherwise specified.
The MIME-Version header uses the syntax 'version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT'. It is required at the top level of a message but not for each body part of a multipart entity; it is required for embedded headers of a message/body only if the embedded message itself claims to be MIME-conformant.
IANA maintains registries for MIME Content-Type/subtype values and for access-type values for Message/External-Body. New standard subtypes require a published specification and IANA approval per Appendix E. The entire content-transfer-encoding namespace (except 'X-' tokens) is reserved to IANA for future use.
Message/External-Body and other mechanisms that cause a mail reader to automatically fetch external content can be exploited to cause unintended network connections or reveal user information to third-party servers. Implementations should alert users before fetching externally-referenced content.
The application/PostScript content type presents security risks because PostScript is a full Turing-complete programming language capable of causing arbitrary actions on the recipient's system, including file writes and command execution. User agents must protect recipients by restricting PostScript interpreter capabilities, running PostScript in a sandbox, or warning users before execution.
Base64 maps 24-bit input groups to 4 output characters drawn from a 65-character alphabet (A–Z, a–z, 0–9, '+', '/', '='). Output lines must be no more than 76 characters. Padding uses '=': two '=' for an 8-bit final quantum, one '=' for a 16-bit final quantum. Characters outside the alphabet must be ignored by decoders.
Multipart entities use a 'boundary' parameter (1–70 characters from a robust character set, not ending with whitespace) as the encapsulation delimiter. Each body part is preceded by '--' + boundary on its own CRLF-terminated line; the final closing delimiter appends '--' after the boundary value. Preamble and epilogue text outside the boundaries must be ignored.
Quoted-Printable encodes octets as '=' followed by two uppercase hexadecimal digits (Rule 1). Printable ASCII chars 33–60 and 62–126 may appear literally (Rule 2). Trailing TAB or SPACE MUST NOT appear at the end of an encoded line (Rule 3). Line breaks must be CRLF (Rule 4). Encoded lines must be no more than 76 characters; a trailing '=' indicates a soft line break (Rule 5).