RFC 2049: MIME Part 5 — Conformance Criteria and Examples

Standards Track MIME — Multipurpose Internet Mail Extensions Published November 1996

ELI5: RFCs 2045–2047 define the rules of MIME. RFC 2049 is the exam: it spells out exactly what your software must do to pass as “MIME-compliant” and provides worked examples to check your implementation against. If MIME were a building code, this is the inspection checklist.

Why This Exists

The MIME specification spans four technical RFCs (2045, 2046, 2047, and 2048). Implementers need a clear answer to: "what is the minimum my software must handle to be MIME-conformant?" RFC 2049 provides that answer, along with canonical test messages that implementers can use to verify their parsers.

Without a conformance document, different implementations would support different subsets of MIME, leading to interoperability failures. RFC 2049 sets the floor: every MIME-aware system must at least handle these content types, encodings, and structures.

How It Works

RFC 2049 defines two levels of conformance, each with specific requirements.

Sending Agent Requirements

A MIME-conformant sending agent (MUA or email library) must:

Always include MIME-Version: 1.0 in every message that uses MIME features.
Include a Content-Type header when the body is anything other than plain US-ASCII text.
Use a valid Content-Transfer-Encoding that ensures the message body can survive transport through 7-bit SMTP gateways (base64 or quoted-printable for non-ASCII content).
Encode header fields correctly using RFC 2047 encoded-words when non-ASCII characters appear in headers like Subject or From display names.
Generate valid multipart boundaries that do not appear in any enclosed body part.

Receiving Agent Requirements

A MIME-conformant receiving agent must:

Recognize MIME-Version: 1.0 and treat the message as MIME-encoded.
Parse Content-Type and Content-Transfer-Encoding headers, including all parameters.
Decode base64 and quoted-printable content transfer encodings.
Handle all multipart types — at minimum multipart/mixed, multipart/alternative, multipart/digest, and multipart/parallel. Unknown multipart subtypes must be treated as multipart/mixed.
Handle message/rfc822 — display the encapsulated message or at least offer it for saving.
Handle unrecognized content types gracefully — offer to save the body part as a file rather than crashing or silently discarding it. Unrecognized types should be treated as application/octet-stream.
Decode RFC 2047 encoded-words in header fields.
Handle the charset parameter on text types, supporting at least US-ASCII and ISO-8859-1, and ideally UTF-8.

Robustness Principle

RFC 2049 reinforces Postel's Law for MIME: be strict in what you send, liberal in what you accept. A conformant receiver should make a best effort to display even slightly malformed MIME messages rather than rejecting them outright.

Key Technical Details

Canonical Examples

RFC 2049 includes worked examples of MIME messages. Here is the pattern for a well-formed multipart/alternative message with both plain text and HTML:

MIME-Version: 1.0
From: sender@example.com
To: recipient@example.com
Subject: MIME conformance test
Content-Type: multipart/alternative; boundary="boundary42"

--boundary42
Content-Type: text/plain; charset=us-ascii

This is the plain text version.

--boundary42
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><body><p>This is the <strong>HTML</strong> version.</p></body></html>

--boundary42--

Handling Unknown Types

A key conformance requirement: when a receiving agent encounters a Content-Type it does not understand, it must treat it as application/octet-stream and offer to save it. This rule ensures forward compatibility — new media types can be defined without breaking existing clients.

; Unknown type encountered by a client
Content-Type: application/vnd.custom-format
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="data.custom"

; Conformant client treats this as application/octet-stream
; and offers the user a "Save As" dialog

Unknown Multipart Subtypes

Similarly, unknown multipart subtypes must be treated as multipart/mixed. This means the client displays each part sequentially. For example, multipart/report (defined later in RFC 3462) will still display correctly in older clients that treat it as mixed.

Minimum Charset Support

Conformant implementations must support at least:

US-ASCII — the baseline
ISO-8859-1 — Western European characters (Latin-1)

In practice, any modern implementation must support UTF-8. Not doing so in 2024+ is a conformance failure in spirit, even if the 1996 spec did not mandate it.

The MIME/Non-MIME Boundary

Messages without a MIME-Version: 1.0 header are treated as pre-MIME plain ASCII text, regardless of whether they happen to contain Content-Type headers. The MIME-Version header is the gatekeeper: without it, MIME processing does not activate.

Common Mistakes

Crashing on unknown Content-Types. The spec is explicit: treat unknown types as application/octet-stream. Libraries that throw exceptions on unknown types are non-conformant and will break as new media types are registered.
Treating unknown multipart subtypes as errors. They must be treated as multipart/mixed. A common bug is to reject or skip multipart/report, multipart/signed, or other extension types.
Ignoring charset on text/* types. Text content without a charset declaration defaults to US-ASCII. Displaying it as UTF-8 may work for ASCII content but will produce garbled output for legacy ISO-8859-1 messages.
Stripping MIME-Version from forwarded messages. When forwarding or re-sending, the MIME-Version header must be preserved. Without it, the receiving client may not process the MIME structure at all.
Partial base64/QP decoding. Both decoders must handle edge cases: base64 padding, QP soft line breaks (=\r\n), and trailing whitespace. Incomplete decoders produce corrupted output for legitimate messages.
Not offering a save option for unrenderable parts. A conformant client must let the user save any body part, even if it cannot display it. Silently discarding parts violates the spec and loses data.

Deliverability Impact

Conformant MIME structure is a deliverability baseline. Non-conformant messages — missing MIME-Version, broken multipart boundaries, incorrect encodings — are hallmarks of spam tools. Spam filters use MIME conformance as a quality signal.
Include both text/plain and text/html. RFC 2049's examples demonstrate multipart/alternative with both formats. This is not just good practice; many spam filters penalize HTML-only messages. The text/plain part must have meaningful content, not just "View this email in your browser."
Valid Content-Transfer-Encoding prevents corruption. A message that declares quoted-printable but contains raw 8-bit data will be mangled by 7-bit SMTP gateways. This causes rendering failures at the recipient, even if the message reaches the inbox.
Correct charset declarations prevent mojibake. Declaring charset=us-ascii for UTF-8 content makes accented characters unreadable. Recipients may report the message as spam rather than trying to decode it.
Well-formed MIME improves rendering across clients. A MIME-conformant message renders correctly in Gmail, Outlook, Apple Mail, Thunderbird, and mobile clients. Non-conformant messages may render in one client but break in another, causing complaints and unsubscribes.