What MIME Is And Why It Outlived the Problem It Solved

In 1992 email could carry plain English and nothing else. No attachments, no formatting, no accented characters. MIME fixed that without touching the mail system at all. It added a way for a message to describe its own contents. Everything modern mail does rests on that one idea.

You have met it already if you have ever looked inside a message file. The boundary strings, the Content-Type lines, the blocks of characters where an attachment should be. All of that is MIME. It explains most of what looks strange in the formats mail is stored in.

The Problem It Was Built For

Mail transport was specified for text and the specification meant it. Characters below 128, short lines, nothing that might be mistaken for a control signal.

By the early nineties that was no longer enough. People wanted to send a spreadsheet. They wanted to write in French with the accents intact. They wanted a message that was part text and part something else.

The obvious fix was the one nobody could take. Rewriting the transport would have meant every mail server on earth upgrading at once. A message passes through servers nobody sending it has ever heard of. Whatever solved this had to work while old servers carried on exactly as before.

What MIME Added And What It Left Alone

The solution was to change the message rather than the machinery. A handful of new headers, all of them text, all of them safe for a server that had never heard of them.

RFC 1341 set it out in 1992. It was revised twice. The version in force now is the five document set beginning at RFC 2045, with RFC 2046 covering the type names. The structure has not changed since. What arrives in your inbox today is described the way it was described then, on top of the addressing rules that RFC 5322 still governs.

That restraint is why MIME succeeded where a cleaner design would have failed. It asked permission from nobody.

The Four Headers That Do the Work

Almost everything MIME does runs through a small set of headers. Recognising them makes a raw message readable.

Content-Type carries more than a type. For anything textual it also takes a charset parameter naming the character set, which is what tells a reader whether a byte means an accented letter or something else entirely. Get that wrong and the message arrives as symbols, with nothing damaged and nothing missing.

MIME-Version has said 1.0 since 1992. The documents were revised twice while that number stayed put, which tells you the revisions clarified wording rather than changing the format. There has never been a version two. The header survives as a marker that the standard applies rather than as a version number doing any work.

How One Message Becomes Several Parts

A message stops being a single body and becomes a tree.

Content-Type: multipart/mixed; boundary="outer-7f2a"

--outer-7f2a
Content-Type: multipart/alternative; boundary="inner-3c9b"

  --inner-3c9b
  Content-Type: text/plain
    the message, for a reader that wants plain text

  --inner-3c9b
  Content-Type: text/html
    the same message, with formatting

--outer-7f2a
Content-Type: application/pdf; name="invoice.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment
    the file, converted into characters

--outer-7f2a--

Two things follow from that shape. The plain text and the HTML are the same message written twice, which is why a message can look completely different in two clients. And the attachment is not beside the message, it is inside it, as another branch of the same tree.

The trailing pair of hyphens closes the message. A boundary line ending in two hyphens means no more parts. Truncate a file before that marker and a reader has no way to know whether it reached the end or the file simply stopped, which is one reason a partly downloaded message often shows nothing at all.

Where the Type Names Come From

Content-Type values are not invented by whoever writes the mail program. They come from a public register.

IANA keeps the list. Anything in it is a media type, which is the name MIME types took once they stopped being about mail. Registration runs through a published procedure rather than by convention. A program meeting a type it does not recognise is expected to treat it as an unnamed lump of bytes rather than guess.

What MIME Explains Once You Can See It

Most of the odd behaviour people meet in mail traces back to one of these decisions.

None of these is a fault in MIME. Every row is a message describing itself correctly and a program either ignoring the description or being unable to act on it. The standard did its job in all six cases.

Why It Outlived Email

MIME was written for one job and turned out to answer a much more general question, which is how one program hands another a lump of bytes and says what they are.

That question comes up everywhere. A web server answering a request faces it. A saved web page faces it, which is why an MHT file is built on the same container as a message. Outlook faces it when it wraps a message it cannot express in ordinary mail. It calls the result winmail.dat.

Content-Type: image/png
Content-Transfer-Encoding:
  base64
Content-Disposition:
  inline

Content-Type: image/png
Content-Disposition:
  attachment

So MIME is now less a mail standard than a shared vocabulary. The headers in an EML file and the headers in an HTTP response are describing the same thing in the same words, thirty years after somebody wrote them down for a problem about attachments.

Reading a message file and seeing that structure rather than noise is most of the work. Our EML viewer parses it in a browser tab so the parts come out as parts. The converters do the same job when mail has to move somewhere else.