Die Multipurpose Internet Mail Extensions (MIME) sind Erweiterungen des Internetstandards RFC 822[1] (seit 2008 durch RFC 5322[2] ersetzt), der das Datenformat von E-Mails definiert. Dieser sieht nur den American Standard Code for Information Interchange (ASCII) vor. Die MIME schaffen Kompatibilität für zusätzliche Zeichen wie Umlaute sowie für Multimedia (etwa bei Mail-Anhängen). Sie wurden in RFC 2045,[3] RFC 2046,[4] RFC 2047[5] RFC 2048[6] und RFC 2049[7] definiert. RFC 2048 wurde von der Internet Engineering Task Force als Best Current Practice eingestuft.
Darüber hinaus findet MIME Anwendung bei der Deklaration von Inhalten in verschiedenen Internetprotokollen wie etwa HTTP sowie bei Desktop-Umgebungen wie KDE, Gnome, Xfce oder Aqua.
MIME ermöglicht es, zwischen Sender und Empfänger Informationen über den Typ der übermittelten Daten auszutauschen (Content-Type-Field, Internet Media Type) und gleichzeitig eine für den verwendeten Übertragungsweg geeignete Zeichenkodierung (Content-Transfer-Encoding) festzulegen.
Es sind mehrere Kodierungsmethoden spezifiziert, die die Übertragung von Nicht-ASCII-Zeichen in Texten sowie von Nicht-Text-Dokumenten wie Bildern, Sprache und Video in textbasierten Übertragungssystemen wie E-Mail oder Usenet ermöglichen. Die Nicht-Text-Elemente werden beim Versender kodiert und beim Empfänger wieder dekodiert.
Die Kodierung von Nicht-7-Bit-ASCII-Zeichen erfolgt häufig mittels Quoted-Printable-Kodierung, Binärdaten hingegen werden üblicherweise Base64-kodiert. Bei dieser Kodierungsweise erhöht sich die Gesamtgröße der angehängten Dateien um 33–36 % (Erklärung siehe Base64). Aus 752 KiB werden 1 MiB (1.024 KiB) und aus 1 MiB werden 1393 KiB. Alternativ ist es für Textdaten mittels Content-Transfer-Encoding: 8bit auch möglich, die Nicht-ASCII-Zeichen direkt zu übertragen (die Kodierung muss dabei angegeben sein, z. B. UTF-8 oder ISO 8859-15 für deutsche Texte).
Bei der Verwendung in anderen Protokollen wie etwa HTTP kann auch die Transport-Kodierung binary verwendet werden, bei der beliebige Bytes direkt verschickt werden können, ohne spezielle Kodierung – bei E-Mails ist dies nicht erlaubt.
Es gibt eine Erweiterung dieses Standards namens S/MIME (Secure MIME), der auch das Verschlüsseln und digitale Signieren von Nachrichten erlaubt. Außerdem existiert mit PGP/MIME (beschrieben in RFC 2015[8] und RFC 3156[9]) auch eine PGP-kompatible Erweiterung für sicheren Datenaustausch.
Eine Multipart-Message enthält mehrere Bodyparts, die durch benannte Grenzlinien (boundary) abgegrenzt werden, bei deren Bezeichner sichergestellt werden muss, dass dieser nicht im restlichen Bodypart vorkommt. Häufig geschieht dies durch Wahl einer zufälligen Zeichenfolge, deren Auftreten im restlichen Bodypart unwahrscheinlich ist. Beispiel für eine einfache Multipart-Message (mit einem verkürzten boundary, das hier als frontier festgelegt ist):
MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=frontier This is a multi-part message in MIME format. --frontier Content-Type: text/plain This is the body of the message. --frontier Content-Type: text/html Content-Transfer-Encoding: base64 PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg== --frontier--
Einzelne Bodyparts werden dabei durch die Sequenz aus einleitenden zwei Querstrichen (Bindestrich-Minuszeichen) und Boundary eingeleitet und der letzte durch dieselbe Sequenz mit auch abschließenden zwei Querstrichen.
Dieser erste Teil der Spezifikationen, RFC 2045,[3] führt grundlegende zusätzliche Felder im Kopf von E-Mails ein:
Das Content-Transfer-Encoding gibt an, ob die Übertragung nach Internetstandard RFC 6152[10] erfolgen soll, dies stattgefunden hat, oder eine Kodierung für Internetstandard RFC 822[1] erfolgt ist, die beim Empfänger wieder rückgängig gemacht werden muss:
Was kein Text ist, erfordert, sofern der ESMTP-Server nicht Binärdaten nach RFC 3030[11] (BDAT-Befehl) akzeptiert, auf jeden Fall Kodierung, die dann grundsätzlich nach Base64 erfolgt. Nichts weiter als beliebigen Text enthaltende E-Mails bedürfen hingegen keiner Umformung:
From: <adam@example.org> To: <eva@example.org> Subject: Umlaute dank MIME MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit
Wären die drei zusätzlichen Kopfzeilen nicht, wäre diese Zeile nicht leserlich.
Dieser zweite Teil der Spezifikationen, RFC 2046,[4] definiert für das Feld Content-Type Haupttypen und Untertypen von Inhalten.
Generell können jedoch auch weitere Internet Media Types verwenden werden, deren konkrete Verarbeitung dann dem Mailprogramm überlassen bleibt.
Als Parameter dieses Haupttyps ist die Angabe eines Zeichensatzes vorgesehen. Als Untertyp ist einfacher Text ohne Formatierung vordefiniert:
Als Untertyp für Bilder ist JPEG vordefiniert:
Als Untertyp für Ton ist der Codec des ISDN, G.711 vordefiniert:
Als Untertyp für Filme ist MPEG vordefiniert:
Dieser Haupttyp ist für Daten von Anwendungsprogrammen vorgesehen. Vordefiniert sind zwei Untertypen:
Dieser Haupttyp ist für Kombinationen mehrerer Inhalte vorgesehen. Vordefiniert sind fünf Untertypen:
Dieser Haupttyp ist zur Handhabung anderer E-Mails vorgesehen. Vordefiniert sind drei Untertypen:
Dieser dritte Teil der Spezifikationen hebt auch für den Betreff und andere Felder im Kopf von E-Mails die Beschränkung auf den englischen Zeichensatz auf.
Ursprünglich war es nicht erlaubt, im Betreff von E-Mails Umlaute oder andere Sonderzeichen zu verwenden, sondern nur die in ASCII definierten Zeichen. Ein Betreff wie „Schöne Grüße“ konnte dann, je nachdem, von welchen Programmen die E-Mail übertragen wurde, als „Sch?ne Gr??e“, „Sch�ne Gr��e“ oder „Schvne Gr|_e“ ankommen. Um diese Probleme zu beheben, wurde in RFC 1522[16] im Jahr 1993 ein Verfahren definiert, wie der Betreff beim Absender codiert und beim Empfänger wieder decodiert wird, ohne dass während der Übertragung die Daten verfälscht werden. Dieses besteht aus folgendem Schema:
=?Zeichensatz?Kodierung?Kodierter Text?=Gemäß RFC 2047[5] gibt es viele gleichwertige Varianten, die Betreffzeile „Schöne Grüße“ zu codieren:
=?UTF-8?B?U2Now7ZuZSBHcsO8w59l?==?ISO-8859-1?B?U2No9m5lIEdy/N9l?==?UTF-8?Q?Sch=C3=B6ne_Gr=C3=BC=C3=9Fe?==?ISO-8859-1?Q?Sch=F6ne_Gr=FC=DFe?=Bei all diesen Varianten sind keine Umlaute mehr zu sehen, die Übertragung ist also gesichert. Dafür ist der Betreff nicht mehr direkt menschenlesbar. Bei den unteren beiden Varianten (mit der Kodierung Q für Quoted-Printable) kann man den Text noch erahnen, bei den oberen beiden (mit der Kodierung B für Base64) ist überhaupt nichts mehr erkennbar. Es sind jedoch alle Informationen enthalten, damit der ursprüngliche Betreff beim Empfänger wieder decodiert werden kann.
Dieser vierte Teil der Spezifikationen, mittlerweile RFC 4289,[17] beschreibt die Registrierung zusätzlicher Erweiterungen bei der Internet Assigned Numbers Authority. Die dort registrierten Media Types sind vielfältig und umfassen auch ausdrücklich überholte und missbilligte.[18] Schon 1994 wurden Registrierungen ohne Berücksichtigung der MIME akzeptiert.[19] Seit 1995 ist die gesamte Registrierung nur noch Best Current Practice.[6] Ende 2005 wurde die Registrierung von Media Types aus der Spezifikation der MIME herausgenommen, um verbreiteten Missverständnissen entgegenzuwirken.[20] Wie sich ein registrierter Media Type zu MIME verhält, erschließt sich nur aus den Spezifikationen.
Dieser fünfte Teil der Spezifikationen, RFC 2049,[7] legt Mindestanforderungen an E-Mail-Programme fest:
MIME-Version: 1.0RFC 1847[21] definiert Verschlüsselung und elektronische Signatur mittels MIME grundlegend. Zwei zusätzliche Media Types sind dafür vorgesehen:
Die in RFC 5751[22] definierten Secure/Multipurpose Internet Mail Extensions (S/MIME) setzen Cryptographic Message Syntax darauf auf.
Die in RFC 2015[8] definierte MIME Security with Pretty Good Privacy (PGP/MIME) setzt stattdessen Pretty Good Privacy (PGP) auf.