Multipurpose Internet Mail Extensions

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche

Die Multipurpose Internet Mail Extensions (MIME) sind Erweiterungen des Internetstandards RFC 822 (seit 2008 durch RFC 5322 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, RFC 2046, RFC 2047, RFC 2048 und RFC 2049 definiert. RFC 2048 wurde von der Internet Engineering Task Force nur 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.

Allgemeine Beschreibung[Bearbeiten]

MIME ermöglicht es, zwischen Sender und Empfänger Informationen über den Typ der übermittelten Daten auszutauschen (Content-Type-Feld, Internet Media Type) und gleichzeitig eine für den verwendeten Übertragungsweg sichere 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 s. Base64). Aus 752 KiB werden 1 MiB (1024 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 und RFC 3156) 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. 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 message with multiple parts in MIME format.
 --frontier
 Content-Type: text/plain

 This is the body of the message.
 --frontier
 Content-Type: application/octet-stream
 Content-Transfer-Encoding: base64

 PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg
 Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg=
 --frontier--

Details der Spezifikation[Bearbeiten]

MIME Part 1 – Format of Internet Message Bodies[Bearbeiten]

Dieser erste Teil der Spezifikationen, RFC 2045, führt grundlegende zusätzliche Felder im Kopf von E-Mails ein:

  1. MIME-Version
  2. Content-type
  3. Content-Transfer-Encoding

Das Content-Transfer-Encoding gibt an, ob die Übertragung nach Internetstandard RFC 6152 erfolgen soll, dies stattgefunden hat, oder eine Kodierung für Internetstandard RFC 822 erfolgt ist, die beim Empfänger wieder rückgängig gemacht werden muss:

Was kein Text ist, erfordert auf jeden Fall Kodierung, die dann grundsätzlich nach Base64 erfolgt. Nichts weiter als beliebigen Text enthaltende E-Mails bedürfen hingegen keiner Umformung:

Beispiel[Bearbeiten]

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.

MIME Part 2 – Media Types[Bearbeiten]

Dieser zweite Teil der Spezifikationen, RFC 2046, definiert für das Feld Content-type Haupttypen und Untertypen von Inhalten:

text[Bearbeiten]

Als Parameter dieses Haupttyps ist die Angabe eines Zeichensatzes vorgesehen. Als Untertyp ist einfacher Text ohne Formatierung vordefiniert:

  • text/plain

image[Bearbeiten]

Als Untertyp für Bilder ist JPEG vordefiniert:

  • image/jpeg

audio[Bearbeiten]

Als Untertyp für Ton ist der Codec des ISDN vordefiniert:

  • audio/basic

video[Bearbeiten]

Als Untertyp für Filme ist MPEG vordefiniert:

  • video/mpeg

application[Bearbeiten]

Dieser Haupttyp ist für Daten von Anwendungsprogrammen vorgesehen. Vordefiniert sind zwei Untertypen:

  • application/octet-stream
Dieser Untertyp soll zum Speichern der Daten führen und ausdrücklich nicht zum Starten eines Anwendungsprogramms.
Dieser Untertyp soll zum Drucken der Daten führen.

multipart[Bearbeiten]

Dieser Haupttyp ist für Kombinationen mehrerer Inhalte vorgesehen. Vordefiniert sind fünf Untertypen:

  • multipart/mixed
Dieser Untertyp ist für Zusammenstellungen in einer bestimmten Reihenfolge vorgesehen.
  • multipart/alternative
Dieser Untertyp ist für gleiche Inhalte in unterschiedlichen Formaten vorgesehen, von denen nur das passendste präsentiert werden soll. Typischerweise ist eines der Formate ein vordefinierter Untertyp der MIME.
  • multipart/digest
Dieser Untertyp ist dazu vorgesehen, eine Übersicht der Inhalte zu liefern.
  • multipart/parallel
Dieser Untertyp ist für Systeme vorgesehen, die alle Typen von Inhalten zugleich präsentieren können.
  • multipart/related
Dieser Untertyp ist separat in RFC 2387 definiert und zur Kombination mehrerer Inhalte vorgesehen, die nur zusammen Sinn ergeben. Die in RFC 2557 definierte MIME Encapsulation of Aggregate Documents baut darauf auf. Sie war die Konsequenz aus dem Umstand, dass Hypertext Markup Language kein Standard für MIME werden konnte.[1] Zudem wurde der Begriff Internet Media Type und schließlich der Begriff XHTML Media Type für Ausrichtung auf das Hypertext Transfer Protocol statt auf das Simple Mail Transfer Protocol geprägt.[2]

message[Bearbeiten]

Dieser Haupttyp ist zur Handhabung anderer E-Mails vorgesehen. Vordefiniert sind drei Untertypen:

  • message/rfc822
Dieser Untertyp ist dazu vorgesehen, mehrere herkömmliche E-Mails aufzunehmen.
  • message/partial
Dieser Untertyp ist dazu vorgesehen, eine große E-Mail in mehrere Teile zu zerlegen, diese nacheinander zu versenden und sie automatisch wieder zusammenzusetzen.
  • message/external-body
Dieser Untertyp ist dazu vorgesehen, nur eine Verknüpfung zu einer anderen E-Mail zu enthalten.

MIME Part 3 – Header Extensions for Non-ASCII Text[Bearbeiten]

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.

MIME Part 4 – Registration Procedures[Bearbeiten]

Dieser vierte Teil der Spezifikationen, mittlerweile RFC 4289, 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.[3] Schon 1994 wurden Registrierungen ohne Berücksichtigung der MIME akzeptiert.[4] Seit 1995 ist die gesamte Registrierung nur noch Best Current Practice.[5] Ende 2005 wurde die Registrierung von Media Types aus der Spezifikation der MIME herausgenommen, um verbreiteten Missverständnissen entgegenzuwirken.[6] Wie sich ein registrierter Media Type zu MIME verhält, erschließt sich nur aus den Spezifikationen.

MIME Part 5 – Conformance Criteria and Examples[Bearbeiten]

Dieser fünfte Teil der Spezifikationen, RFC 2049, legt Mindestanforderungen an E-Mail-Programme fest:

  • Obligatorische zusätzliche Kopfzeile jeder erstellten E-Mail:
MIME-Version: 1.0
  • Senden aller nicht RFC 822 entsprechenden E-Mails mit Kodierungen und Kopfzeilen der MIME.
  • Melden von Zeichensätzen der ISO 8859 in empfangenen E-Mails.
  • Erkennen und Darstellen des Inhaltstyps message/rfc822.
  • Weitgehendes Erkennen und Darstellen des Inhaltstyps multipart.
  • Verarbeiten aller nicht erkannten Inhaltstypen als Inhaltstyp octet-stream.

Verschlüsselung[Bearbeiten]

RFC 1847 definiert Verschlüsselung und elektronische Signatur mittels MIME grundlegend. Zwei zusätzliche Media Types sind dafür vorgesehen:

  • multipart/signed
  • multipart/encrypted

Die in RFC 5751 definierten Secure/Multipurpose Internet Mail Extensions setzen Cryptographic Message Syntax darauf auf.

Die in RFC 2015 definierte MIME Security with Pretty Good Privacy setzt stattdessen Pretty Good Privacy auf.

Spezifikationen[Bearbeiten]

  • RFC 2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
  • RFC 2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
  • RFC 2047 MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text
  • RFC 2048 Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures
  • RFC 2049 Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples

Einzelnachweise[Bearbeiten]

  1. RFC 2854 – The 'text/html' Media Type. Internet Engineering Task Force. Abgerufen am 25. Juli 2011.
  2. XHTML Media Types. World Wide Web Consortium. 30. April 2002. Abgerufen am 25. Juli 2011.
  3. MIME Media Types. Internet Corporation for Assigned Names and Numbers. Abgerufen am 25. Juli 2011.
  4. RFC 1590 – Media Type Registration Procedure. Internet Engineering Task Force. Abgerufen am 25. Juli 2011.
  5. RFC 2048 – MIME Part Four: Registration Procedures. Internet Engineering Task Force. Abgerufen am 25. Juli 2011.
  6. RFC 4288 – Media Type Specifications and Registration Procedures. Internet Engineering Task Force. Abgerufen am 25. Juli 2011.