MIME let email carry anything by adding a content-type header, not a new mail system.

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.

Add a header that says what the body is

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

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.

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.