Multipurpose Internet Mail Extensions

aus Wikipedia, der freien Enzyklopadie

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 Kompatibilitat fur zusatzliche Zeichen wie Umlaute sowie fur Multimedia (etwa bei Mail-Anhangen). 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.

Daruber 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 ermoglicht es, zwischen Sender und Empfanger Informationen uber den Typ der ubermittelten Daten auszutauschen (Content-Type-Field, Internet Media Type) und gleichzeitig eine fur den verwendeten Ubertragungsweg geeignete Zeichenkodierung (Content-Transfer-Encoding) festzulegen.

Es sind mehrere Kodierungsmethoden spezifiziert, die die Ubertragung von Nicht-ASCII-Zeichen in Texten sowie von Nicht-Text-Dokumenten wie Bildern, Sprache und Video in textbasierten Ubertragungssystemen wie E-Mail oder Usenet ermoglichen. Die Nicht-Text-Elemente werden beim Versender kodiert und beim Empfanger wieder dekodiert.

Die Kodierung von Nicht-7-Bit-ASCII-Zeichen erfolgt haufig mittels Quoted-Printable-Kodierung, Binardaten hingegen werden ublicherweise Base64-kodiert. Bei dieser Kodierungsweise erhoht sich die Gesamtgrosse der angehangten Dateien um 33-36 % (Erklarung siehe Base64). Aus 752 KiB werden 1 MiB (1.024 KiB) und aus 1 MiB werden 1393 KiB. Alternativ ist es fur Textdaten mittels Content-Transfer-Encoding: 8bit auch moglich, die Nicht-ASCII-Zeichen direkt zu ubertragen (die Kodierung muss dabei angegeben sein, z. B. UTF-8 oder ISO 8859-15 fur 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 konnen, ohne spezielle Kodierung - bei E-Mails ist dies nicht erlaubt.

Es gibt eine Erweiterung dieses Standards namens S/MIME (Secure MIME), der auch das Verschlusseln und digitale Signieren von Nachrichten erlaubt. Ausserdem existiert mit PGP/MIME (beschrieben in RFC 2015^[8] und RFC 3156^[9]) auch eine PGP-kompatible Erweiterung fur sicheren Datenaustausch.

Eine Multipart-Message enthalt mehrere Bodyparts, die durch benannte Grenzlinien (boundary) abgegrenzt werden, bei deren Bezeichner sichergestellt werden muss, dass dieser nicht im restlichen Bodypart vorkommt. Haufig geschieht dies durch Wahl einer zufalligen Zeichenfolge, deren Auftreten im restlichen Bodypart unwahrscheinlich ist. Beispiel fur eine einfache Multipart-Message (mit einem verkurzten 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 abschliessenden zwei Querstrichen.

Dieser erste Teil der Spezifikationen, RFC 2045,^[3] fuhrt grundlegende zusatzliche 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 Ubertragung nach Internetstandard RFC 6152^[10] erfolgen soll, dies stattgefunden hat, oder eine Kodierung fur Internetstandard RFC 822^[1] erfolgt ist, die beim Empfanger wieder ruckgangig gemacht werden muss:

• 7bit - keine Kodierung, Text enthalt nur ASCII-Zeichen
• 8bit - keine Kodierung, Text enthalt auch Nicht-ASCII-Zeichen, Ubertragung mittels Extended SMTP
• binary - keine Kodierung, binarer Inhalt
• quoted-printable - Kodierung von Steuerzeichen und Nicht-ASCII-Zeichen durch Ersetzung mit deren Hexadezimalwert
• base64 - Kodierung durch Transformation in eine 6-Bit-Darstellung

Was kein Text ist, erfordert, sofern der ESMTP-Server nicht Binardaten nach RFC 3030^[11] (BDAT-Befehl) akzeptiert, auf jeden Fall Kodierung, die dann grundsatzlich nach Base64 erfolgt. Nichts weiter als beliebigen Text enthaltende E-Mails bedurfen hingegen keiner Umformung:

From:
To:
Subject: Umlaute dank MIME
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 8bit
Waren die drei zusatzlichen Kopfzeilen nicht, ware diese Zeile nicht leserlich.

Dieser zweite Teil der Spezifikationen, RFC 2046,^[4] definiert fur das Feld Content-Type Haupttypen und Untertypen von Inhalten.

Generell konnen jedoch auch weitere Internet Media Types verwenden werden, deren konkrete Verarbeitung dann dem Mailprogramm uberlassen bleibt.

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

• text/plain

• text/html

Als Untertyp fur Bilder ist JPEG vordefiniert:

• image/jpeg

Als Untertyp fur Ton ist der Codec des ISDN, G.711 vordefiniert:

• audio/basic

Als Untertyp fur Filme ist MPEG vordefiniert:

• video/mpeg

Dieser Haupttyp ist fur Daten von Anwendungsprogrammen vorgesehen. Vordefiniert sind zwei Untertypen:

• application/octet-stream
  • Dieser Untertyp soll zum Speichern der Daten fuhren und ausdrucklich nicht zum Starten eines Anwendungsprogramms.
• application/postscript
  • Dieser Untertyp soll zum Drucken der Daten fuhren.

Dieser Haupttyp ist fur Kombinationen mehrerer Inhalte vorgesehen. Vordefiniert sind funf Untertypen:

• multipart/mixed
  • Dieser Untertyp ist fur Zusammenstellungen in einer bestimmten Reihenfolge vorgesehen.
• multipart/alternative
  • Dieser Untertyp ist fur gleiche Inhalte in unterschiedlichen Formaten vorgesehen, von denen nur das passendste prasentiert werden soll. Typischerweise ist eines der Formate ein vordefinierter Untertyp der MIME.
• multipart/digest
  • Dieser Untertyp ist dazu vorgesehen, eine Ubersicht der Inhalte zu liefern.
• multipart/parallel
  • Dieser Untertyp ist fur Systeme vorgesehen, die alle Typen von Inhalten zugleich prasentieren konnen.
• multipart/related
  • Dieser Untertyp ist separat in RFC 2387^[12] definiert und zur Kombination mehrerer Inhalte vorgesehen, die nur zusammen Sinn ergeben. Die in RFC 2557^[13] definierte MIME Encapsulation of Aggregate Documents baut darauf auf. Sie war die Konsequenz aus dem Umstand, dass Hypertext Markup Language (HTML) kein Standard fur MIME werden konnte.^[14] Zudem wurde der Begriff Internet Media Type und schliesslich der Begriff XHTML Media Type fur Ausrichtung auf das Hypertext Transfer Protocol (HTTP) statt auf das Simple Mail Transfer Protocol (SMTP) gepragt.^[15]

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

• message/rfc822
  • Dieser Untertyp ist dazu vorgesehen, mehrere herkommliche E-Mails aufzunehmen.
• message/partial
  • Dieser Untertyp ist dazu vorgesehen, eine grosse 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 Verknupfung zu einer anderen E-Mail zu enthalten.

Dieser dritte Teil der Spezifikationen hebt auch fur den Betreff und andere Felder im Kopf von E-Mails die Beschrankung auf den englischen Zeichensatz auf.

Ursprunglich 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 ,,Schone Grusse" konnte dann, je nachdem, von welchen Programmen die E-Mail ubertragen wurde, als ,,Sch?ne Gr??e", ,,Schne Gre" 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 Empfanger wieder decodiert wird, ohne dass wahrend der Ubertragung die Daten verfalscht werden. Dieses besteht aus folgendem Schema:

• =?Zeichensatz?Kodierung?Kodierter Text?=

Gemass RFC 2047^[5] gibt es viele gleichwertige Varianten, die Betreffzeile ,,Schone Grusse" 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 Ubertragung ist also gesichert. Dafur ist der Betreff nicht mehr direkt menschenlesbar. Bei den unteren beiden Varianten (mit der Kodierung Q fur Quoted-Printable) kann man den Text noch erahnen, bei den oberen beiden (mit der Kodierung B fur Base64) ist uberhaupt nichts mehr erkennbar. Es sind jedoch alle Informationen enthalten, damit der ursprungliche Betreff beim Empfanger wieder decodiert werden kann.

Dieser vierte Teil der Spezifikationen, mittlerweile RFC 4289,^[17] beschreibt die Registrierung zusatzlicher Erweiterungen bei der Internet Assigned Numbers Authority. Die dort registrierten Media Types sind vielfaltig und umfassen auch ausdrucklich uberholte und missbilligte.^[18] Schon 1994 wurden Registrierungen ohne Berucksichtigung 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 Missverstandnissen entgegenzuwirken.^[20] Wie sich ein registrierter Media Type zu MIME verhalt, erschliesst sich nur aus den Spezifikationen.

Dieser funfte Teil der Spezifikationen, RFC 2049,^[7] legt Mindestanforderungen an E-Mail-Programme fest:

• Obligatorische zusatzliche Kopfzeile jeder erstellten E-Mail:
  • MIME-Version: 1.0
• Senden aller nicht RFC 822^[1] entsprechenden E-Mails mit Kodierungen und Kopfzeilen der MIME.
• Melden von Zeichensatzen 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.

RFC 1847^[21] definiert Verschlusselung und elektronische Signatur mittels MIME grundlegend. Zwei zusatzliche Media Types sind dafur vorgesehen:

• multipart/signed
• multipart/encrypted

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.

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

1. | ^{a b c} RFC: 822 - Standard for the Format of ARPA Internet Text Messages. 13. August 1982 (englisch).
2. | RFC: 5322 - Internet Message Format. Oktober 2008 (englisch).
3. | ^{a b} RFC: 2045 - Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. (englisch).
4. | ^{a b} RFC: 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. (englisch).
5. | ^{a b} RFC: 2047 - MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text. (englisch).
6. | ^{a b} RFC: 2048 - Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures. (englisch).
7. | ^{a b} RFC: 2049 - Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples. (englisch).
8. | ^{a b} RFC: 2015 - MIME Security with Pretty Good Privacy (PGP). Oktober 1996 (englisch).
9. | RFC: 3156 - MIME Security with OpenPGP. August 2001 (englisch).
10. | RFC: 6152 - SMTP Service Extension for 8-bit MIME Transport. Marz 2011 (englisch).
11. | RFC: 3030 - SMTP Service Extensions for Transmission of Large and Binary MIME Messages. Dezember 2000 (englisch).
12. | RFC: 2387 - The MIME Multipart/Related Content-type. August 1998 (englisch).
13. | RFC: 2557 - MIME Encapsulation of Aggregate Documents, such as HTML (MHTML). Marz 1999 (englisch).
14. | RFC: 2854 - The 'text/html' Media Type. Juni 2000 (englisch).
15. | XHTML Media Types. World Wide Web Consortium, 30. April 2002, abgerufen am 25. Juli 2011 (englisch).
16. | RFC: 1522 - MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text. Marz 1993 (englisch). spater erweitert durch RFC 2047
17. | RFC: 4289 - Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures. Dezember 2005 (englisch).
18. | MIME Media Types. Internet Corporation for Assigned Names and Numbers, abgerufen am 25. Juli 2011 (englisch).
19. | RFC: 1590 - Media Type Registration Procedure. (englisch).
20. | RFC: 4288 - Media Type Specifications and Registration Procedures. (englisch).
21. | RFC: 1847 - Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted. Oktober 1995 (englisch).
22. | RFC: 5751 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 - Message Specification. Januar 2010 (englisch).

Abgerufen von ,,https://de.wikipedia.org/w/index.php?title=Multipurpose_Internet_Mail_Extensions&oldid=254750462"

Kategorien:

• E-Mail
• Internetstandard
• Multipurpose Internet Mail Extensions