MIME: what RFC 2045-2049 and Content-Disposition define

RFC 5322 headers and bodies are 7-bit US-ASCII text by default: no standard way to carry a binary attachment, HTML, an image, or a non-English subject line. Five RFCs, 2045 through 2049, published together in 1996, close that gap.

What MIME defines

RFC 2045 defines the format of message bodies and the Content-Transfer-Encoding header. RFC 2046 defines media types: text/*, image/*, multipart/*, application/*, and the multipart subtypes that hold more than one part. RFC 2047 defines encoded-words, letting non-ASCII text appear in a header value.

RFC 2048 originally defined registration procedures for new media types, later superseded specifically on that point by RFC 4288 and RFC 4289 in 2005. RFC 2049 defines conformance criteria and worked examples. RFC 2183, published the following year, defines Content-Disposition: whether a MIME part renders inline or offers as a downloadable attachment.

"STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for (1) textual message bodies in character sets other than US-ASCII, (2) an extensible set of different formats for non-textual message bodies, (3) multi-part message bodies, and (4) textual header information in character sets other than US-ASCII."

How it works

A Content-Type header declares the body's type and subtype, with a boundary parameter on any multipart/* type marking where each part starts and ends. A Content-Transfer-Encoding header declares how binary data survives transport that assumes text: base64 for arbitrary binary, quoted-printable for mostly-ASCII text with occasional non-ASCII bytes, 7bit/8bit/binary for data that needs no re-encoding.

Non-ASCII header values use the encoded-word syntax =?charset?encoding?text?=, for example =?UTF-8?B?<base64>?=. A Content-Disposition header on any part marks it inline or attachment, optionally with a filename.

Anatomy

Content-Type: type/subtype pair, plus boundary on multipart types.

Content-Transfer-Encoding:

Encoded-word syntax: =?charset?encoding?text?=, four parts: the charset, the encoding letter (B for base64 or Q for quoted-printable), the encoded text, and the =?/?= delimiters.

Content-Disposition:

Worked example

A message with a plain-text body, a PDF attachment, and a non-ASCII subject line:

Subject: =?UTF-8?B?Q2F0w6lnb3JpZSBWSVA6IHZvdHJlIGZhY3R1cmU=?=
Content-Type: multipart/mixed; boundary="frontier"

--frontier
Content-Type: text/plain

Your invoice is attached.

--frontier
Content-Type: application/pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="invoice.pdf"

(base64-encoded content)

--frontier--

The Subject line decodes to "Catégorie VIP: votre facture," the encoded-word syntax carrying the accented characters inside an otherwise ASCII-only header. The PDF part declares base64 encoding and Content-Disposition: attachment, telling a mail client to offer it as a download rather than render it inline.

Where this doesn't reach

MIME structures and encodes content. It doesn't authenticate or encrypt it. Message encryption is a separate, later standard, S/MIME or OpenPGP, layered on top, not covered by this cluster today.

Content-Disposition's filename is a suggestion a client can ignore or sanitize. RFC 2183 doesn't require or define any sanitization; that's left to the receiving application.

Check it yourself

View the raw source of any received email with an attachment. In Gmail, open the message and select "Show original," then find its Content-Type, Content-Transfer-Encoding, and Content-Disposition headers directly.

Where it fits

This page covers what structures the body message format leaves opaque. For what transports the finished, encoded message, see SMTP. For the full standards landscape, see the reference hub.

FAQ

What's the difference between base64 and quoted-printable encoding?

Base64 encodes any binary data as ASCII text, at roughly a 33% size cost, and is the standard choice for attachments. Quoted-printable is more efficient for content that's already mostly ASCII with occasional non-ASCII bytes, common for HTML email bodies.

Does MIME encrypt attachments?

No. MIME structures and encodes content so it survives transport intact. Encryption is a separate concern, handled by S/MIME or OpenPGP, not by RFC 2045-2049.

How does a non-ASCII subject line work if headers are ASCII-only?

Via the encoded-word syntax RFC 2047 defines: =?charset?encoding?text?=, embedding the non-ASCII text as base64 or quoted-printable inside an otherwise-ASCII header value.

Can a mail client trust the filename in Content-Disposition?

Not blindly. RFC 2183 defines the field as a suggestion; it doesn't require sanitization, so a receiving application is responsible for handling an unexpected or malicious filename safely.

RFC reference

RFCs covered: RFC 2045-2049 (MIME), RFC 2183 (Content-Disposition). Superseded / updated by: RFC 2048 is superseded on the media-type registration point by RFC 4288 and RFC 4289. The rest have no successor.