MIME ermöglichte es E-Mails, beliebige Inhalte zu transportieren, indem ein Content-Type-Header hinzugefügt wurde – kein neues Mailsystem.

Frühe Internet-E-Mail war ausschließlich ASCII, sodass der Nachrichtentext kein Bild und keine Datei in einer Form enthalten konnte, auf die sich alle Clients einigten. MIME, die Multipurpose Internet Mail Extensions, wurde entwickelt, um dies zu ändern.

MIME entstand aus dem Andrew Messaging System an der Carnegie Mellon University als plattformübergreifendes Datenformat und wurde erstmals von Mitentwickler Nathaniel Borenstein und anderen im Juni 1992 als RFC 1341 spezifiziert; die aktuelle Version ist die RFC-2045/2046/2047-Reihe von 1996.

Das Design war bewusst klein gehalten: Ein Content-Type-Header benennt, was der Teil ist, eine Content-Transfer-Encoding wandelt Binärdaten in ASCII um, und eine Multipart-Grenze erlaubt es, dass ein Textkörper viele Teile enthält. Die Nachricht wird weiterhin wie zuvor über SMTP übertragen.

Da die Erweiterung headerbasiert und optional war, konnte jeder Client die Unterstützung nach eigenem Zeitplan hinzufügen, und MIME wurde schnell zum Standardweg, um Anhänge und Rich-Text-E-Mails zu versenden, und später zur Grundlage der Content-Type-Idee des Webs selbst.

Einen Header hinzufügen, der angibt, was der Textkörper ist

Ein Content-Type-Header teilt dem Empfänger mit, was ein Teil ist, sodass er nach Regel dekodieren kann

base64 lässt beliebige Binärdaten einen reinen ASCII-Transport passieren

Multipart-Grenzen lassen eine Nachricht Text und Anhänge zusammen enthalten

Da die Änderung auf Header-Ebene erfolgte, erforderte die Einführung keinen gemeinsamen Umstieg

Um ein weit verbreitetes System zu erweitern, fügt man ein kleines optionales Stück Struktur hinzu, kein neues System: Ein Header, der angibt, was die Nutzlast ist, ermöglicht es jedem Implementierer, ihn nach eigenem Ermessen zu übernehmen.

MIME wurde zum universellen Container für E-Mail-Anhänge und ist der Grund, warum der Content-Type-Header seine Idee übernahm, um Web-Ressourcen zu beschreiben. Die ursprüngliche Spezifikation war dünn in Bezug auf die Darstellung, daher wurde Content-Disposition in RFC 2183 hinzugefügt; in der Praxis wählen viele Clients den anzuzeigenden Teil noch immer nach ihrer eigenen Logik statt nach dem Rat des Standards.