Multipurpose Internet Mail Extensions

Grundidee und Funktionsweise

Multipurpose Internet Mail Extensions (MIME) erweitern das E-Mail-Datenformat des früheren RFC 822, der seit 2008 durch RFC 5322 ersetzt ist. RFC 822 sah ursprünglich nur ASCII-Zeichen vor. MIME ermöglicht deshalb die Übertragung zusätzlicher Zeichen wie Umlauten sowie von Multimedia-Inhalten und Dateianhängen.

MIME übermittelt zwei wichtige Informationen: den Inhaltstyp einer Nachricht oder eines Nachrichtenteils (Content-Type-Field beziehungsweise Internet Media Type) und die für den Übertragungsweg passende Kodierung (Content-Transfer-Encoding). Nicht-Text-Inhalte werden beim Absender kodiert und beim Empfänger wieder dekodiert. Dadurch können Bilder, Sprache, Videos und andere Dokumente auch über textbasierte Systeme wie E-Mail oder Usenet übertragen werden.

Für Nicht-ASCII-Zeichen in Texten wird häufig Quoted-Printable verwendet. Binärdaten werden üblicherweise mit Base64 kodiert. Base64 vergrößert die Gesamtgröße angehängter Dateien um 33–36 %: Aus 752 KiB werden 1 MiB (1.024 KiB), aus 1 MiB werden 1393 KiB. Mit Content-Transfer-Encoding: 8bit können Textdaten auch direkt übertragen werden; dabei muss der Zeichensatz angegeben sein, zum Beispiel UTF-8 oder ISO 8859-15 für deutsche Texte. In Protokollen wie HTTP ist zusätzlich die Transport-Kodierung binary möglich. Sie erlaubt die direkte Übertragung beliebiger Bytes, ist bei E-Mails jedoch nicht erlaubt.

MIME wird außerdem bei der Inhaltsdeklaration in Protokollen wie HTTP und in Desktop-Umgebungen wie KDE, Gnome, Xfce oder Aqua eingesetzt.

Nachrichtenteile und Kodierungen

RFC 2045 führt drei grundlegende zusätzliche E-Mail-Kopffelder ein:

• MIME-Version
• Content-Type
• Content-Transfer-Encoding

Das Content-Transfer-Encoding beschreibt, ob der Inhalt ohne Kodierung übertragen werden kann oder vor der Übertragung umgewandelt werden muss:

• 7bit: keine Kodierung; der Text enthält nur ASCII-Zeichen.
• 8bit: keine Kodierung; der Text enthält auch Nicht-ASCII-Zeichen und wird mittels Extended SMTP übertragen.
• binary: keine Kodierung; der Inhalt ist binär.
• quoted-printable: Steuerzeichen und Nicht-ASCII-Zeichen werden durch ihre Hexadezimalwerte ersetzt.
• base64: Der Inhalt wird in eine 6-Bit-Darstellung umgewandelt.

Nicht-Text-Inhalte müssen kodiert werden, sofern der ESMTP-Server keine Binärdaten nach RFC 3030 mit dem BDAT-Befehl akzeptiert; grundsätzlich erfolgt diese Kodierung mit Base64. Reine Text-E-Mails benötigen hingegen keine solche Umformung.

Eine typische Nachricht enthält beispielsweise:

From: [email protected] To: [email protected] Subject: Umlaute dank MIME MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit

Die Angabe von Zeichensatz und Kodierung sorgt dafür, dass deutsche Sonderzeichen korrekt verarbeitet werden.

Eine Multipart-Message besteht aus mehreren Bodyparts, also einzelnen Nachrichtenteilen. Diese werden durch eine benannte Grenzlinie (boundary) getrennt. Der Boundary-Bezeichner darf im übrigen Inhalt nicht vorkommen; häufig wird deshalb eine zufällige Zeichenfolge gewählt. Jeder Teil beginnt mit zwei Bindestrich-Minuszeichen und dem Boundary-Namen, zum Beispiel --frontier. Der letzte Teil endet mit derselben Folge und zusätzlich zwei abschließenden Bindestrich-Minuszeichen: --frontier--.

Inhaltstypen und Untertypen

RFC 2046 ordnet Inhalte über Content-Type einem Haupttyp und einem Untertyp zu. Weitere Internet Media Types sind möglich; ihre konkrete Verarbeitung bleibt dann dem E-Mail-Programm überlassen.

• text: Für Text. Als Parameter ist die Angabe eines Zeichensatzes vorgesehen. Vordefiniert sind text/plain für einfachen, unformatierten Text und text/html für HTML-Inhalte.
• image: Für Bilder. Vordefiniert ist image/jpeg.
• audio: Für Ton. Vordefiniert ist audio/basic mit dem ISDN-Codec G.711.
• video: Für Filme. Vordefiniert ist video/mpeg.
• application: Für Daten von Anwendungsprogrammen. application/octet-stream soll die Daten speichern und ausdrücklich kein Anwendungsprogramm starten. application/postscript soll die Daten drucken.
• multipart: Für Kombinationen mehrerer Inhalte. multipart/mixed fasst Inhalte in einer bestimmten Reihenfolge zusammen. multipart/alternative enthält denselben Inhalt in unterschiedlichen Formaten, von denen nur das passendste präsentiert werden soll. multipart/digest dient einer Übersicht der Inhalte. multipart/parallel ist für Systeme gedacht, die alle Inhaltstypen gleichzeitig präsentieren können. multipart/related kombiniert Inhalte, die nur gemeinsam sinnvoll sind; dieser Untertyp ist separat in RFC 2387 definiert.
• message: Für die Handhabung anderer E-Mails. message/rfc822 kann mehrere herkömmliche E-Mails aufnehmen. message/partial zerlegt eine große E-Mail in mehrere Teile, die nacheinander versendet und automatisch zusammengesetzt werden. message/external-body enthält nur eine Verknüpfung zu einer anderen E-Mail.

Nicht-ASCII-Text in Kopfzeilen

RFC 2047 hebt die ASCII-Beschränkung für den Betreff und andere E-Mail-Kopfzeilen auf. Ursprünglich durften dort keine Umlaute oder sonstigen Sonderzeichen stehen. Ein Betreff wie „Schöne Grüße“ konnte dadurch beispielsweise als „Sch?ne Gr??e“, „Sch�ne Gr��e“ oder „Schvne Gr|_e“ ankommen.

Das bereits in RFC 1522 im Jahr 1993 beschriebene Verfahren kodiert den Text beim Absender und dekodiert ihn beim Empfänger. Das Schema lautet:

=?Zeichensatz?Kodierung?Kodierter Text?=

Für „Schöne Grüße“ sind unter anderem diese Varianten möglich:

• =?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?=

B steht für Base64, Q für Quoted-Printable. Während Q-kodierte Betreffzeilen teilweise noch lesbar erscheinen, ist bei Base64 meist nichts vom ursprünglichen Text zu erkennen. Die vollständigen Informationen zur Wiederherstellung des ursprünglichen Betreffs bleiben jedoch enthalten.

Registrierung, Anforderungen und Sicherheit

MIME ist in RFC 2045 bis RFC 2049 festgelegt. RFC 2048 wurde von der Internet Engineering Task Force als Best Current Practice eingestuft. Der vierte Teil, mittlerweile RFC 4289, beschreibt die Registrierung zusätzlicher Erweiterungen bei der Internet Assigned Numbers Authority. Die registrierten Media Types umfassen auch überholte und missbilligte Typen. Seit 1995 ist die gesamte Registrierung nur noch Best Current Practice. Ende 2005 wurde die Registrierung von Media Types aus der MIME-Spezifikation herausgenommen, weil es dazu verbreitete Missverständnisse gab.

RFC 2049 legt Mindestanforderungen für E-Mail-Programme fest. Jede erstellte E-Mail muss die zusätzliche Kopfzeile MIME-Version: 1.0 enthalten. Nicht RFC-822-konforme E-Mails müssen mit MIME-Kopfzeilen und geeigneten Kodierungen gesendet werden. Programme sollen Zeichensätze der ISO 8859 in empfangenen E-Mails melden, message/rfc822 erkennen und darstellen sowie multipart-Inhalte weitgehend erkennen und darstellen. Nicht erkannte Inhaltstypen werden als octet-stream verarbeitet.

Für Sicherheit definiert RFC 1847 grundsätzlich Verschlüsselung und elektronische Signaturen mit MIME. Dafür gibt es die Media Types multipart/signed und multipart/encrypted. S/MIME (Secure/Multipurpose Internet Mail Extensions), definiert in RFC 5751, verwendet darauf aufbauend Cryptographic Message Syntax. PGP/MIME, beschrieben in RFC 2015 und RFC 3156, verwendet stattdessen Pretty Good Privacy (PGP).