MIME (RFCs 2045 to 2049) gives a message body a type, an encoding and, for multipart types, a structure of nested parts. Each part has its own header (MIME fields only) and body, separated by an empty line, just like a whole message. This page follows RFC 2045, RFC 2046, RFC 2183, RFC 2231 and the other RFCs named below, all read 2026-11-12.
MIME fields
| Field | Meaning |
|---|---|
MIME-Version | 1.0, in the message header. |
Content-Type | type/subtype and parameters. Without it, text/plain; charset=us-ascii. |
Content-Transfer-Encoding | See encodings; default 7bit. |
Content-ID | <id@domain>; RFC 2392 lets another part refer to it as the URL cid:id@domain. |
Content-Description | Text. |
Content-Disposition | RFC 2183: inline or attachment, with parameters filename, creation-date, modification-date, read-date and size. |
Content-Language, Content-Location | RFC 3282 and RFC 2557. |
Parameters are ; name=value, the value quoted when it has special
characters. RFC 2231 adds character sets and long values:
filename*=UTF-8''na%C3%AFve.txt, and continuations
name*0=, name*1=…
Media types
Top-level types: text (parameter charset; also
format=flowed from RFC 3676), image, audio,
video, application (such as
application/octet-stream and application/pdf),
message and multipart from RFC 2046, model
from RFC 2077 and font from RFC 8081. message/rfc822 is a
whole message inside a part; message/delivery-status is a delivery
status notification (RFC 3464).
| Multipart subtype | Meaning |
|---|---|
mixed | Parts in order, such as a text and attachments. |
alternative | The same content in several forms, in increasing order of preference: the plainest first, the richest last. A reader should show the last one it can. |
related | RFC 2387: a root part and the parts it refers to. |
digest | Parts are messages by default. |
parallel | Parts to be shown together. |
signed | RFC 1847: the content, then its signature; the protocol parameter names the signature type. |
encrypted | RFC 1847: control information, then the encrypted data. |
report | RFC 6522: delivery and read reports. |
Multipart bodies
- The
boundaryparameter is 1 to 70 characters that do not occur in the parts. - Each part starts after a line
--boundary; the last part ends with a line--boundary--. - The CR LF before a boundary line belongs to the boundary, not to the part.
- Text before the first boundary (the preamble) and after the last (the epilogue) is ignored. RFC 2046 notes that many programs put a note for readers without MIME support in the preamble.
Content-Type: multipart/alternative; boundary="b1"
--b1
Content-Type: text/plain; charset=UTF-8
Hello
--b1
Content-Type: text/html; charset=UTF-8
<p>Hello</p>
--b1--Transfer encodings
| Value | Meaning |
|---|---|
7bit | ASCII lines of at most 998 characters; no encoding. |
8bit | Lines that may hold bytes over 127; needs a mail path that allows it. |
binary | Any bytes, no line rules. |
quoted-printable | Mostly readable text: a byte is written =XX in upper-case hex when it is not printable ASCII or is =; lines at most 76 characters, with = at the end of a line as a soft break; white space at the end of a line must be encoded. |
base64 | Groups of 3 bytes as 4 characters from A–Z a–z 0–9 + /, padded with =; lines at most 76 characters. |
Multipart entities and message/rfc822 bodies may only use
7bit, 8bit or binary; their parts carry their
own encodings.