Summary

  • RFC 2049 defined conformance for an open-ended media system without requiring every user agent to understand every subtype.
  • Its decisive fallback was conservative: unknown transfer encodings, unknown character sets and unknown non-text types descended toward application/octet-stream, while raw non-text bytes were not to be shown as text.
  • The document’s word “safe” described transport through known conforming RFC 821/822 systems and protection from accidental raw display. It did not certify a file, sender, decoder, rendering or outcome.

A standard for not knowing

An extensible type system creates an immediate problem. The sender may know a format that the receiver has never seen. If conformance required identical format libraries, no implementation could remain conformant as the registry grew. If ignorance had no rule, the same bytes could be printed, executed, discarded or guessed differently.

RFC 2049 chose a minimum behaviour rather than universal comprehension. A conforming mail user agent had to recognise the MIME control surfaces and know when to stop interpreting. That is the historical object of Part Five. The earlier parts defined fields, encodings, media families and header text; Part Five made a receiver’s ignorance interoperable.

The requirement began with ordinary creation and custody. A conforming agent generated MIME-Version: 1.0 on messages it created. It recognised Content-Transfer-Encoding, decoded quoted-printable and base64, and recognised 7bit, 8bit and binary. If an underlying transport could not carry 8bit or binary, the sender had to encode and label the body appropriately. The label did not repair bytes after the fact; it told the receiver which reversible operation was expected.

When the encoding itself was unknown

The strictest retreat came before media interpretation. An unrecognised Content-Transfer-Encoding forced the MIME entity to be treated as application/octet-stream, even when its declared Content-Type was familiar. A receiver could not safely apply image, text or application semantics until it knew how to recover the represented octets.

The present errata record matters here. EID 5470, held for a future document update, observes that the original sentence grammatically gives a Content-Transfer-Encoding a Content-Type. Its proposed wording supplies the implicit subject: a MIME entity with an unrecognised encoding. The technical boundary is unchanged, but the erratum’s status must not be upgraded into replacement text.

This ordering separated two questions. Did the receiver reconstruct the intended octet sequence? If so, did it understand the media declaration? Passing the second question’s label to a handler while failing the first would let a recognisable name disguise unrecovered data.

The top-level family bought only a small amount of knowledge

For text, RFC 2049 required US-ASCII display and at least notice of other character sets. An unknown text subtype could be offered in raw form only when the character set was known and after canonical form had been converted to local form. An unknown character set became octet-stream instead. “Text” was therefore not permission to spray undecoded octets onto a screen.

Unknown image, audio and video subtypes also became octet-stream at minimum. For application, a recipient had to be able to remove quoted-printable or base64 and place the result in a user file. That was a custody capability, not an instruction to execute the result. RFC 2046 warned that a general-purpose viewer inherits the security exposure of its most dangerous supported format.

Composite types had different fallbacks. A conforming implementation recognised multipart/mixed, avoided redundant display in multipart/alternative, applied the special default inside multipart/digest, and treated an unknown multipart subtype as mixed. It recognised message/rfc822 recursively; an unknown message subtype became octet-stream. Completely unrecognised Content-Type values likewise became parameter-free octet-stream, with saving to a file or choosing a program described only as possible local handling.

“Safe” stopped at the screen

After listing ten requirements, RFC 2049 explained what MIME-conformant meant. It was assumed safe to send virtually any properly marked data because the receiver could at least treat it as undifferentiated binary and would not simply splash it onto an unsuspecting user’s screen. It also called conformant data safe in the sense that known systems conforming to RFC 821 and RFC 822 would neither be broken by it nor break it.

Those are narrow claims. Opaque bytes can still be malicious. A chosen program can be vulnerable. A correct decoder can reveal content the user did not authorise. A message may be forged, truncated, altered before receipt, mishandled by a nonconforming relay or rendered incorrectly. The conformance label records a minimum set of behaviours; it does not observe their execution in a particular product.

Even successful display is outside the promise. For an unfamiliar character set, merely informing the user was enough. For an unknown subtype, saving was enough. The standard deliberately allowed useful refusal.

The bad mail system was evidence, not permission

RFC 2049 also described a messier network. It said many widely deployed nonconforming MTAs altered messages according to local storage conventions or were simply broken. NUL, TAB, trailing spaces, long lines, non-invariant characters, a period alone on a line and line-leading From could be lost or changed. Base64 satisfied the narrowest portable alphabet and line constraints; quoted-printable survived most, but not every, gateway named by the document.

The RFC then drew a bright line. These were not recommendations for MTAs. RFC 821 prohibited the whitespace changes and line wrapping being described. The guidance asked composers to survive invalid reality without laundering that reality into the protocol contract.

That distinction remains the article’s evidentiary limit. A normative rule says what a conforming agent must do. A 1996 warning records that nonconforming agents existed. Neither proves which client performed which step, how widely a rule was deployed, or what a user ultimately saw.

Status, errata and what the record can prove

RFC Editor’s current information page labels RFC 2049 a Draft Standard; the document itself says Standards Track and dates from November 1996. That publication record establishes the specification’s place, not a census of implementations.

The verified EID 3933 corrects another boundary: requirement ten should refer to RFC 822’s word grammar and RFC 2047’s encoded-word recognition rules, not RFC 2049 section 4. It improves the cross-reference; it does not turn an encoded display word into a sender identity or routing address.

The durable achievement was disciplined ignorance. MIME let the vocabulary expand because a receiver did not need to improvise when the vocabulary outran its software. It could decode what it knew, preserve what it did not, and refuse to confuse binary custody with textual understanding.

Sources