In einer Reihe neuer Internet-Standards werden Möglichkeiten für Multimedia-Mail definiert:
RFC 1521 - Spezifikation des Formates von
Nachrichteninhalten (MIME - Teil 1) [3]
RFC 1522 - Darstellung von Nicht-ASCII Text in Nachrichtenköpfen (Header) [12]
RFC 1524 - Flexible Konfiguration von User Agents für Multimedia-Mail [4]
Mit MIME ist ein allgemeiner Mechanismus für die Spezifikation von Nachrichtenformaten verfügbar. Damit wird es möglich, neben ASCII-Text z.B. Bild- und Audio-Daten oder Texte in anderen Zeichensätzen (auch gemischt) in definierten Formaten über das Internet auszutauschen. MIME ist nicht auf ein bestimmtes Transportprotokoll festgelegt. Die neuen Möglichkeiten erfordern keinerlei Änderungen in den MTAs.
MIME ist keine Neudefinition von RFC 822, d.h. die Grundstruktur der Nachrichten (Header + Body) bleibt unangetastet. Es werden einige neue Header definiert und der Mail-Body strukturiert. So zeigt die folgende Headerzeile, daß die Nachricht dem MIME-Standard entspricht:
MIME-Version: 1.0
Das Konzept beinhaltet die Einführung von Typen und Subtypen (Tab. 1). Der Inhaltstyp wird im neuen Header Content-Type definiert. Weiterhin gibt es häufig noch Parameter, die den Subtyp näher beschreiben, z.B. Zeichensatz, Trennzeichenkette bei mehreren Teilen oder Zugriffsvorschrift auf externe Daten.
Mit dem Inhaltstyp multipart/mixed ist die Möglichkeit gegeben, mehrere Teile (mit unterschiedlichen Inhaltstypen) in einer Mitteilung zu verschicken. Damit wird gegenüber der getrennten Verschickung (wie heute oft üblich) ein besseres Verhältnis von übertragener Nutz- zu Verwaltungsinformation erreicht; für den Nutzer ist die Handhabung ebenfalls bequemer. Mit multipart/parallel kann sogar eine simultane Präsentation der Mail-Bestandteile beim Empfänger erreicht werden (vielleicht Bewegtbilder mit Sprache), wenn dessen UA dies unterstützt.
Einen Spezialfall stellt die Übertragung des gleichen Informationsinhalts in unterschiedlichen Repräsentationen dar (multipart/alternative). Auf diese Weise wird erreicht, daß eine Nachricht von UAs mit unterschiedlichen Fähigkeiten vernünftig ausgewertet werden kann. (Besser als die Mitteilung ''Can't display PostScript'' ist die Darstellung als ASCII-Text.)
Das Gegenstück zum Versenden mehrerer Inhaltsteile in einer Mitteilung stellt die Aufteilung einer Nachricht auf mehrere separat transportierte Einheiten dar (message/partial). Dies ist vorteilhaft, da mit steigender Mail-Länge die Wahrscheinlichkeit von Abbrüchen (Leitungsüberlastung, Geräteausfälle) steigt. Im Unterschied zu Filetransferprotokollen (FTAM, FTP) besitzt SMTP (derzeit) keine Mechanismen zum Wiederaufsetzen nach solchen Situationen; die gesamte Nachricht muß wiederholt werden.
Mit dem Nachrichtentyp message/external-body wird ein Zeiger auf externe Daten geliefert, z.B. auf Files in FTP-Archiven. Die möglicherweise umfangreichen Daten sind in der Nachricht selbst nicht enthalten, können aber bei Bedarf mit Hilfe dieser Referenz automatisch beschafft werden (z.B. anonymes FTP).
Der Typ message/rfc822 erlaubt das Einschließen kompletter Nachrichten, z.B. weitergeleitete oder zurückgewiesene Mail.
Weitere Inhaltstypen können bei der Internet Assigned Numbers Authority (IANA) registriert werden. Über diesen Weg sind bisher z.B. application/rtf, image/tiff und video/quicktime eingeführt worden.
Die neuen Inhaltstypen müssen geeignet kodiert werden (Tab. 2), damit die von den Transportsystemen gesetzten Bedingungen erfüllt werden. Im allgemeinen wird man die Kodierung so wählen, daß sich der Mail-Inhalt für das Mail-Transportprotokoll SMTP wie bisher als ASCII-Text darstellt. Für andere Protokolle, wie z.B. für uucp oder das erweiterte SMTP nach [10], kann auf eine 7-Bit-Kodierung verzichtet werden. Die verwendete Kodierung wird im Header Content-Transfer-Encoding festgehalten.
Weitere optionale Header-Felder sind Content-ID und Content-Description.
Abb. 1 zeigt den Aufbau einer MIME-Nachricht, so wie sie über SMTP übertragen wird. Sie besteht aus Text mit Sonderfunktionen, einem Audio-Teil und einer Referenz auf ein Postscript-File in einem FTP-Archiv. Ein MIME-unkundiger Mail-User-Agent stellt die Nachricht dann auch wie hier abgebildet dar, die Präsentation durch einen MIME-fähigen UA ist in Abb. 2 dargestellt.
To: ... MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=PART.103.saturn.705940.1 From: ... --PART.103.saturn.705940.1 Content-type: text/richtext Content-Transfer-Encoding: quoted-printable Deine Frage:Wie funktioniert MetaMail ? m=F6chte ich im folgenden beantworten. In der folgenden Referenz findest Du eine Graphik zur PP-Struktur.--PART.103.saturn.705940.1 Content-type: audio/basic Content-Description: Nutzung von MetaMail Content-Transfer-Encoding: base64 /n/+/n7++/98//5+fn7+/n7/fn/+fv7+fn79/3/9fv//f/7+fP5+fvt9/v7... --PART.103.saturn.705940.1 Content-type: message/external-body; access-type=ANON-FTP; site="ftp.tu-chemnitz.de"; mode="binary"; directory="/pub/documentation"; name="PP.ps"; Content-type: application/postscript --PART.103.saturn.705940.1--
[12] enthält einen Kodierungsvorschlag, wodurch auch Nicht-ASCII Zeichen in Mail-Headern verwendet werden können. Das betrifft nur solche Header, die nicht vom Transportsystem interpretiert werden, sondern nur für den Nutzer relevant sind, wie z.B. Subject, Comment, Content-Description und Kommentare/Phrasen in To, From etc.
Folgende Kodierung wird verwendet:
=? Zeichensatz (z.B. iso-8859-1) ? Kodierung (q=quoted printable) ? kodierter Text ?=
Ein Beispiel veranschaulicht die Anwendung:
Subject: Schöne Grüße wird vor dem Senden kodiert:
Subject: =?iso-8859-1?q?Sch=F6ne Gr=FC=DFe?=
Der entsprechend fähige User Agent des Empfängers wird dies wieder in ''menschenlesbarer'' Form präsentieren.