The encyclopedia · Software & IT · Technical decision · 1992–1996
MIME let email carry anything by adding a content-type header, not a new mail system.
MIME added a content-type header, an encoding rule and multipart boundaries to the RFC mail format, so one message could carry text, a photo or a file.
the IETF · Bellcore · Carnegie Mellon University
the move
Early internet mail was ASCII-only, so the body of a message could not carry an image or a file in a way every client agreed on. MIME, the Multipurpose Internet Mail Extensions, was devised to change that.
MIME grew out of the Andrew Messaging System at Carnegie Mellon University as a cross-platform data format, and was first specified by co-creator Nathaniel Borenstein and others as RFC 1341 in June 1992; the current version is the RFC 2045/2046/2047 set from 1996.
Its design was deliberately small: a Content-Type header names what the part is, a Content-Transfer-Encoding turns binary into ASCII, and a multipart boundary lets one body contain many parts. The message still travels over SMTP as before.
Because the extension was header-based and optional, each client could add support on its own schedule, and MIME quickly became the standard way to send attachments and rich-text email, and later the basis of the web's own content-type idea.
why it works
- A content-type header tells the receiver what a part is, so it can decode by rule
- base64 lets arbitrary binary pass through an ASCII-only transport
- Multipart boundaries let one message hold text and attachments together
- Because the change was header-level, adoption did not require a common switchover
what transfers
To extend a widely deployed system, add a small optional piece of structure, not a new system: a header saying what the payload is lets each implementer adopt it on their own.
what came after
MIME became the universal container for email attachments and is why the Content-Type header borrowed its idea to describe web resources. The original spec was thin on presentation, so Content-Disposition was added in RFC 2183; in practice many clients still choose the part to display using their own logic rather than the standard's advice.
references
spotted an error? The archive wants to know.