Inhaltskonvertierung

  • Artikel

Gilt für: Exchange Server 2013

Inhaltskonvertierung ist der Vorgang des richtigen Formatierens einer Nachricht für jeden Empfänger. Die Entscheidung, eine Inhaltskonvertierung für eine Nachricht durchzuführen, hängt vom Ziel und Format der zu verarbeitenden Nachricht ab. In Microsoft Exchange Server 2013 gibt es zwei verschiedene Arten der Inhaltskonvertierung:

  • Nachrichtenkonvertierung für externe Empfänger: Diese Art der Inhaltskonvertierung umfasst die TNEF-Konvertierungsoptionen (Transport Neutral Encapsulation Format) und Nachrichtencodierungsoptionen für externe Empfänger. Bei Nachrichten, die an Empfänger innerhalb der Exchange-Organisation gesendet werden, ist dieser Inhaltskonvertierungstyp nicht erforderlich. Diese Art der Inhaltskonvertierung wird vom Kategorisierungsmodul im Transportdienst auf dem Postfachserver verarbeitet. Die Kategorisierung erfolgt für jede Nachricht, nachdem eine neu eingegangene Nachricht in die Übermittlungswarteschlange eingestellt wurde. Zusätzlich zur Empfänger- und Routingauflösung wird die Inhaltskonvertierung auf die Nachricht angewendet, bevor die Nachricht in eine Übermittlungswarteschlange eingestellt wird. Enthält eine einzelne Nachricht mehrere Empfänger, ermittelt das Kategorisierungsmodul die geeignete Codierung für jeden Nachrichtenempfänger. Die Ablaufverfolgung für die Inhaltskonvertierung erfasst keine Fehler der Inhaltskonvertierung, die beim Kategorisierungsmodul bei der Konvertierung von Nachrichten auftreten, die an externe Empfänger gesendet werden.

  • MAPI-Konvertierung für interne Empfänger: Diese Art der Inhaltskonvertierung wird vom Postfachtransportdienst verarbeitet. Der Postfachtransportdienst befindet sich auf Postfachservern und dient zur Übermittlung von Nachrichten zwischen Postfachdatenbanken auf dem lokalen Server und dem Transportdienst auf Postfachservern. Genauer gesagt ist es der Postfachtransport-Übermittlungsdienst, der Nachrichten aus dem Postausgang des Absenders an den Transportdienst auf einem Postfachserver übermittelt. Der Postfachtransport-Zustellungsdienst übermittelt Nachrichten vom Transportdienst auf einem Postfachserver an den Posteingang des Empfängers. Der Postfachtransport-Übermittlungsdienst konvertiert alle ausgehenden Nachrichten aus MAPI, und der Postfachtransport-Zustellungsdienst konvertiert alle eingehenden Nachrichten nach MAPI. Die Ablaufverfolgung für die Inhaltskonvertierung erfasst MAPI-Konvertierungsfehler. Weitere Informationen finden Sie unter Ablaufverfolgung für die Inhaltskonvertierung.

In diesem Thema werden die Optionen für die Nachrichtenkonvertierung für externe Empfänger erläutert.

Exchange- und Outlook-Nachrichtenformate

In der folgenden Liste werden die grundlegenden Nachrichtenformate beschrieben, die in Exchange und Microsoft Outlook verfügbar sind:

  • Nur-Text: Eine Nur-Text-Nachricht verwendet nur US-ASCII-Text, wie in RFC 2822 beschrieben. Die Nachricht kann keine unterschiedlichen Schriftarten oder andere Textformatierungen enthalten. Folgende zwei Formate können für eine Nur-Text-Nachricht verwendet werden:

    • Die Nachrichtenkopfzeilen und der Nachrichtentext bestehen beide aus US-ASCII-Text. Anlagen müssen mithilfe von Uuencode codiert sein. Uuencode steht für Unix-to-Unix Encoding und definiert einen Codieralgorithmus zum Speichern von binären Anlagen im Text einer E-Mail unter Verwendung von US-ASCII-Textzeichen.

    • Die Nachricht wird mit einem Content-Type-Wert von text/plainund einem Content-Transfer-Encoding-Wert von 7bit für die Textteile einer multipart-Nachricht (mehrteilig) MIME-codiert. Alle Nachrichtenanlagen werden mit Quoted-printable- oder Base64-Codierung codiert. Wenn Sie eine Nur-Text-Nachricht in Outlook verfassen und senden, ist die Nachricht standardmäßig MIME-codiert mit dem Content-Type-Wert text/plain.

  • HTML: Eine HTML-Nachricht unterstützt Textformatierung, Hintergrundbilder, Tabellen, Aufzählungszeichen und andere grafische Elemente. Gemäß Definition muss eine HTML-formatierte Nachricht MIME-codiert sein, damit diese Formatierungselemente erhalten bleiben.

  • Rich-Text-Format (RTF): RTF unterstützt Textformatierung und andere grafische Elemente. RTF steht für TNEF. TNEF und RTF können austauschbar verwendet werden. Das Format für Rich-Text-Nachrichten unterscheidet sich vollständig von dem in Microsoft Word verfügbaren Format für Rich-Text-Dokumente.

    Nur Outlook und einige andere MAPI-E-Mail-Clients verstehen RTF-Nachrichten.

  • TNEF: Das transportneutrale Kapselungsformat ist ein Microsoft-spezifisches Format zum Kapseln von MAPI-Nachrichteneigenschaften. Eine TNEF-Nachricht enthält eine Nur-Text-Version der Nachricht sowie eine Anlage, die eine gepackte Version der formatierten Originalversion der Nachricht enthält. Üblicherweise trägt diese Anlage den Namen „Winmail.dat". Die Anlage „Winmail.dat" enthält folgende Informationen:

    • Ursprüngliche formatierte Version der Nachricht, z. B. Schriftarten, Textgrößen und Textfarben

    • OLE-Objekte, z. B. eingebettete Bilder oder eingebettete Microsoft Office-Dokumente

    • Spezielle Outlook-Features, z. B. benutzerdefinierte Formulare, Abstimmungsschaltflächen oder Besprechungsanfragen

    • Reguläre Nachrichtenanlagen, die Bestandteil der Originalnachricht waren

      Die sich ergebende Nur-Text-Nachricht lässt sich in den folgenden Formaten darstellen:

    • RFC 2822-konforme Nachricht, die nur aus US-ASCII-Text mit einer Winmail.dat-Anlage besteht, die in Uuencode codiert ist

    • Eine MIME-codierte multipart-Nachricht (mehrteilig) mit einer Anlage Winmail.dat.

      Ein MAPI-kompatibler E-Mail-Client, der TNEF vollständig versteht, z. B. Outlook, verarbeitet die Winmail.dat-Anlage und zeigt den ursprünglichen Nachrichteninhalt an, ohne jemals die Winmail.dat-Anlage anzuzeigen. Ein E-Mail-Client, der TNEF nicht interpretieren kann, stellt eine TNEF-Nachricht möglicherweise auf eine der folgenden Arten dar:

    • Die Nur-Text-Version der Nachricht wird angezeigt, und die Nachricht enthält eine Anlage namens Winmail.dat, Win.dat oder einen anderen generischen Namen wie Att_nnnnn_.dat oder Att_nnnnn_.eml, wobei der Platzhalter nnnnn eine Zufallszahl darstellt.

    • Die Nur-Text-Version der Nachricht wird angezeigt. Die TNEF-Anlage wird ignoriert oder entfernt. Das Ergebnis ist eine Nur-Text-Nachricht.

    • Messagingserver, die TNEF interpretieren können, können so konfiguriert werden, dass TNEF-Anlagen aus eingehenden Nachrichten entfernt werden. Das Ergebnis ist eine Nur-Text-Nachricht. Darüber hinaus verstehen einige E-Mail-Clients wie Microsoft Outlook Express TNEF möglicherweise nicht, erkennen aber TNEF-Anlagen und ignorieren sie. Das Ergebnis ist eine Nur-Text-Nachricht.

      Es gibt Dienstprogramme von Drittanbietern, die bei der Konvertierung von Winmail.dat-Anlagen helfen können.

      TNEF wird von allen Versionen von Exchange ab Exchange Server, Version 5.5 interpretiert.

  • Summary Transport Neutral Encapsulation Format (STNEF): STNEF entspricht TNEF. STNEF-Nachrichten werden aber anders als TNEF-Nachrichten codiert. Insbesondere sind STNEF-Nachrichten immer MIME-codiert und weisen immer den Content-Transfer-Encoding-Wert Binary auf. Deshalb ist keine Nur-Text-Darstellung der Nachricht vorhanden, und im Text der Nachricht ist keine gesonderte Winmail.dat-Anlage enthalten. Die gesamte Nachricht wird unter Verwendung von nur binären Daten dargestellt. Nachrichten mit dem Content-Transfer-Encoding-Wert Binary können nur zwischen SMTP-Messagingservern übertragen werden, die die SMTP-Erweiterungen BINARYMIME und CHUNKING unterstützen und ankündigen, wie in RFC 3030 definiert. Die Nachrichten werden immer zwischen SMTP-Messaging übertragen, indem der BDAT-Befehl anstelle des DATA-Standardbefehls verwendet wird.

    STNEF wird von allen Versionen von Exchange seit Exchange 2000 interpretiert. STNEF wird automatisch für alle Nachrichten verwendet, die zwischen Exchange-Servern in der Organisation seit dem mit Exchange Server 2003 eingeführten einheitlichen Modus übertragen werden.

    Exchange sendet nie STNEF-Nachrichten an externe Empfänger. Nur TNEF-Nachrichten können an Empfänger außerhalb der Exchange-Organisation gesendet werden.

Inhaltskonvertierungsoptionen für externe Empfänger

Die Inhaltskonvertierungsoptionen, die in einer Exchange-Organisation für externe Empfänger festgelegt werden können, können in folgende Kategorien untergliedert werden:

  • TNEF-Konvertierungsoptionen: Diese Konvertierungsoptionen geben an, ob TNEF beibehalten oder aus Nachrichten entfernt werden soll, die die Exchange-Organisation verlassen.

  • Nachrichtencodierungsoptionen: Diese Optionen geben Nachrichtencodierungsoptionen an, z. B. MIME- und Nicht-MIME-Zeichensätze, Nachrichtencodierung und Anlagenformate.

Diese Konvertierungs- und Codierungsoptionen sind voneinander unabhängig. So ist es beispielsweise für die MIME- oder Nur-Text-Codierungseinstellungen von Nachrichten ohne Belang, ob TNEF-Nachrichten die Exchange-Organisation verlassen dürfen.

Die Inhaltskonvertierung kann entsprechend der Beschreibung in der folgenden Liste auf unterschiedlichen Ebenen der Exchange-Organisation festgelegt werden:

  • Remotedomäneneinstellungen: Remotedomänen definieren die Einstellungen für ausgehende Nachrichtenübertragungen zwischen der Exchange-Organisation und externen Domänen. Auch wenn für bestimmte Domänen keine Remotedomäneneinträge erstellt werden, ist eine vordefinierte Remotedomäne namens „Standard“ vorhanden, die auf alle Remoteadressräume (*) angewendet wird.

  • Einstellungen für E-Mail-Benutzer und E-Mail-Kontakt: E-Mail-Benutzer und E-Mail-Kontakte sind ähnlich, da beide externe E-Mail-Adressen haben und Informationen zu Personen außerhalb der Exchange-Organisation enthalten. Der Hauptunterschied besteht darin, dass E-Mail-Benutzer über Konten verfügen, die verwendet werden können, um sich bei der Active Directory-Domäne anzumelden und auf Ressourcen in der Organisation zuzugreifen.

  • Outlook-Einstellungen: In Outlook können Sie die in der folgenden Liste beschriebenen Optionen für die Nachrichtenformatierung und -codierung festlegen:

    • Nachrichtenformat: Sie können das Standardnachrichtenformat für alle Nachrichten festlegen. Das Standardnachrichtenformat kann darüber hinaus beim Erstellen einer bestimmten Nachricht außer Kraft gesetzt werden.

    • Internetnachrichtenformat: Sie können steuern, ob TNEF-Nachrichten an Remoteempfänger gesendet werden oder ob sie zuerst in ein kompatibleres Format konvertiert werden. Sie können außerdem verschiedene Nachrichtencodierungsoptionen für Nachrichten angeben, die an Remoteempfänger gesendet werden. Diese Einstellungen gelten nicht für Nachrichten, die an Empfänger in der Exchange-Organisation gesendet werden.

    • Internetempfänger-Nachrichtenformat: Sie können steuern, ob TNEF-Nachrichten an bestimmte Empfänger gesendet werden oder ob sie zuerst in ein kompatibleres Format konvertiert werden. Sie können die Konvertierungsoptionen für bestimmte Kontakte in Ihrem Kontakteordner festlegen und die Konvertierungsoptionen für einen bestimmten Empfänger in den Feldern An, Cc oder Bcc überschreiben, während Sie eine Nachricht verfassen. Diese Konvertierungsoptionen stehen nicht für Empfänger in der Exchange-Organisation zur Verfügung.

    • Optionen für die Codierung von Internetempfängernachrichten: Sie können die MIME- oder Nur-Text-Codierungsoptionen für bestimmte Kontakte in Ihrem Ordner Kontakte steuern und die Konvertierungsoptionen für einen bestimmten Empfänger in den Feldern An, Cc oder Bcc überschreiben, während Sie eine Nachricht verfassen. Diese Konvertierungsoptionen stehen nicht für Empfänger in der Exchange-Organisation zur Verfügung.

    • Internationale Optionen: Sie können die in Nachrichten verwendeten Zeichensätze steuern.

TNEF-Konvertierungsoptionen

Sie können die TNEF-Konvertierungsoptionen auf den folgenden Ebenen angeben:

  • Remotedomäneneinstellungen
  • E-Mail-Benutzer- und E-Mail-Kontakteinstellungen
  • Outlook-Einstellungen, einschließlich:
    • Nachrichtenformat
    • Internet-Nachrichtenformat
    • Internetempfänger-Nachrichtenformat

Nachrichtencodierungsoptionen

Sie können die Nachrichtencodierungsoptionen auf den folgenden Ebenen angeben:

  • Remotedomäneneinstellungen
  • E-Mail-Benutzer- und E-Mail-Kontakteinstellungen
  • Outlook-Einstellungen, einschließlich:
    • Nachrichtenformat
    • Internetnachricht
    • Internetempfänger-Nachrichtenformat
    • Nachrichtenzeichensatz-Codierungsoptionen

Ausführliche Informationen finden Sie unter Nachrichtencodierungsoptionen.

Grundlegendes zur Struktur von E-Mails

Um die Inhaltskonvertierungsoptionen für externe Empfänger besser verstehen zu können, müssen Sie sich mit der Struktur von E-Mails vertraut machen. Die Grundlage einer SMTP-Nachricht bei der Erstellung und beim Senden von E-Mails bildet unformatierter 7-Bit-US-ASCII-Text. Eine SMTP-Standardnachricht besteht aus folgenden Elementen:

  • Nachrichtenumschlag: Der Nachrichtenumschlag ist in RFC 2821 definiert. Er enthält Informationen, die für die Übertragung und Zustellung der Nachricht erforderlich sind. Empfänger bekommen den Nachrichtenumschlag nicht angezeigt, da er vom Nachrichtenübermittlungsprozess generiert wird und nicht tatsächlicher Bestandteil des Nachrichteninhalts ist.

  • Nachrichteninhalte: Die Nachrichteninhalte werden in RFC 2822 definiert. Er besteht aus folgenden Elementen:

    • Nachrichtenkopf: Der Nachrichtenkopf ist eine Sammlung von Kopfzeilenfeldern. Kopfzeilenfelder bestehen aus einem Feldnamen, gefolgt von einem Doppelpunkt (:) Zeichen, gefolgt von einem Feldtext und endet durch eine Cr/LF-Zeichenkombination (Wagenrücklauf/Zeilenvorschub).

      • Ein Feldname muss aus druckbaren US-ASCII-Textzeichen bestehen, mit Ausnahme des Doppelpunkts (:). Insbesondere ASCII-Zeichen mit Werten von 33 bis 57 sowie 59 bis 126 sind zulässig.

      • Ein Feldtext kann aus beliebigen US-ASCII-Zeichen bestehen, mit Ausnahme des Wagenrücklaufzeichens (CR) und des Zeilenvorschubzeichens (LF). Ein Feldtext darf jedoch die Zeichenkombination CR/LF enthalten, wenn sie beim Kopfzeilenumbruch verwendet wird. Headerfaltung ist die Trennung eines einzelnen Kopfzeilenfeldkörpers in mehrere Zeilen, wie in Abschnitt 2.2.3 von RFC 2822 beschrieben. Weitere Anforderungen an die Feldtextsyntax werden in den Abschnitten 3 und 4 von RFC 2822 beschrieben.

    • Nachrichtentext: Der Nachrichtentext ist eine Sammlung von Zeilen mit US-ASCII-Textzeichen, die nach dem Nachrichtenkopf angezeigt werden. Der Nachrichtenkopf und der Nachrichtentext sind durch eine Leerzeile getrennt, die durch die CR/LF-Zeichenkombination abgeschlossen wird. Der Nachrichtentext ist optional. Keine Textzeile im Nachrichtentext darf länger als 997 Zeichen sein. CR- und LF-Zeichen können nur zusammen verwendet werden, um das Ende einer Zeile anzuzeigen.

Wenn SMTP-Nachrichten Elemente enthalten, bei denen es sich nicht um unformatierten US-ASCII-Text handelt, muss die Nachricht codiert werden, um diese Elemente zu erhalten. Der MIME-Standard definiert eine Methode zum Codieren von Inhalten in Nachrichten, bei denen es sich nicht um Text handelt. MIME ermöglicht die Verwendung von Text in anderen Zeichensätzen, Anlagen ohne Text, mehrteiligen Nachrichtentexten und Kopffeldern in anderen Zeichensätzen. MIME ist in RFC 2045, RFC 2046, RFC 2047, RFC 2048 und RFC 2077 definiert. MIME definiert eine Sammlung von Kopffeldern, die zusätzliche Nachrichtenattribute angeben. In der folgenden Tabelle werden einige wichtige MIME-Kopfzeilenfelder beschrieben.

Wichtige MIME-Headerfelder

Name des Kopfzeilenfelds Standardwert Beschreibung
MIME-Version 1.0 Dieses Kopfzeilenfeld ist das erste MIME-Kopfzeilenfeld, das in einer Nachricht im MIME-Format vorkommt. Dieses Headerfeld wird nach den anderen standardmäßigen RFC 2822-Headerfeldern, aber vor allen anderen MIME-Headerfeldern angezeigt. MIME-aktivierte E-Mail-Clients identifizieren anhand dieser Kopfzeilenfelder MIME-codierte Nachrichten. Fehlt dieses Kopfzeilenfeld, identifizieren MIME-aktivierte E-Mail-Clients die Nachricht als unformatierten Text.
Content-Type text/plain Dieses Kopffeld identifiziert den Medientyp des Nachrichteninhalts, wie in RFC 2046 beschrieben. Ein Medientyp besteht aus einem Typ, einem Untertyp und mindestens einem optionalen Parameter, wie z. B. einem charset=-Parameter, der die MIME-Zeichencodierung definiert. Typen, die mit "x-" beginnen, sind nicht standard. Untertypen, die mit "vnd." beginnen, sind herstellerspezifisch. Die IANA (Internet Assigned Numbers Authority) pflegt eine Liste der registrierten Medientypen. Weitere Informationen finden Sie unter MIME-Medientypen.

Der Medientyp multipart ermöglicht die Verwendung mehrerer Nachrichtenteile in derselben Nachricht, indem durch verschiedene Medientypen definierte Abschnitte verwendet werden. Zu den Content-Type-Feldwerten gehören unter anderem text/plain, text/html, multipart/mixed und multipart/alternative.
Content-Transfer-Encoding 7-Bit Dieses Kopfzeilenfeld kann folgende Informationen zu einer Nachricht beschreiben:
  • Den Codieralgorithmus, mit dem alle im Nachrichtentext vorhandenen Nicht-US-ASCII-Text- oder Binärdaten transformiert werden.
  • Einen Indikator, der den aktuellen Zustand des Nachrichtentexts beschreibt.

Eine MIME-Nachricht kann mehrere Werte des Kopfzeilenfelds Content-Transfer-Encoding enthalten. Wenn das Kopfzeilenfeld Content-Transfer-Encoding im Nachrichtenkopf vorkommt, gilt es für den gesamten Text der Nachricht. Wenn das Kopfzeilenfeld Content-Transfer-Encoding in einem der Teile einer multipart-Nachricht (mehrteilig) vorkommt, gilt es nur für diesen Teil der Nachricht.

Bei Anwendung eines Codierungsalgorithmus auf die Nachrichtentextdaten werden diese in unformatierten US-ASCII-Text transformiert. Diese Transformation ermöglicht die Umleitung der Nachricht über ältere SMTP-Messagingservers, die nur Nachrichten in US-ASCII-Text unterstützen. Die Werte des Headerfelds Content-Transfer-Encoding, die angeben, dass ein Codierungsalgorithmus für den Nachrichtentext verwendet wurde, sind wie folgt:

  • Druckbare Anführungszeichen: Dieser Codierungsalgorithmus verwendet druckbare US-ASCII-Zeichen, um die Nachrichtentextdaten zu codieren. Besteht der ursprüngliche Nachrichtentext hauptsächlich aus US-ASCII-Text, erzeugt die Quoted-printable-Codierung relativ lesbare und kompakte Ergebnisse. Alle druckbaren US-ASCII-Textzeichen, mit Ausnahme des Gleichheitszeichens (=), können ohne Codierung dargestellt werden.
  • Base64: Dieser Codierungsalgorithmus basiert hauptsächlich auf dem in RFC 1421 definierten PEM-Standard (Privacy-Enhanced Mail). Die Base64-Codierung verwendet den 64-Zeichenalphabet-Codierungsalgorithmus sowie in PEM definierte Zeichen zum Auffüllen der Ausgabe, um die Nachrichtentextdaten zu codieren. Eine Base64-codierte Nachricht ist üblicherweise 33 % größer als die Ursprungsnachricht. Die Base64-Codierung erzeugt einen vorhersagbaren Zuwachs der Nachrichtengröße und eignet sich optimal für Binärdaten und Nicht-US-ASCII-Text.

Normalerweise trifft man nur sehr selten innerhalb einer Nachricht auf verschiedene Codieralgorithmen.

Wenn kein Codierungsalgorithmus auf den Nachrichtentext angewendet wurde, zeig das Kopfzeichenfeld Content-Transfer-Encoding nur den aktuellen Zustand der Nachrichtentextdaten an. Die folgenden Werte des Headerfelds Content-Transfer-Encoding geben an, dass für den Nachrichtentext keine Codierungsalgorithmen verwendet wurden:

  • 7-Bit: Dieser Wert gibt an, dass die Nachrichtentextdaten bereits im RFC 2822-Format vorliegen. Hierbei müssen insbesondere die folgenden Bedingungen erfüllt sein:
    • Keine Textzeile darf länger als 997 Zeichen sein.
    • Alle Zeichen müssen als US-ASCII-Text mit Zeichenwerten von 1 bis 127 vorliegen.
    • CR- und LF-Zeichen können nur zusammen verwendet werden, um das Ende einer Textzeile anzuzeigen.

    Der gesamte Nachrichtentext kann 7 Bit oder ein Teil des Nachrichtentexts in einer mehrteiligen Nachricht 7 Bit sein. Enthält die multipart-Nachricht andere Teile mit Binärdaten oder Nicht-US-ASCII-Text, müssen diese Teile der Nachricht mit einem der Algorithmen „Quoted-printable" oder „Base64" codiert sein.

    Nachrichten mit 7-Bit-Textkörpern können mithilfe des DATA-Standardbefehls zwischen SMTP-Messagingservern übertragen werden.

  • 8-Bit: Dieser Wert gibt an, dass die Nachrichtentextdaten Nicht-US-ASCII-Zeichen enthalten. Hierbei müssen insbesondere die folgenden Bedingungen erfüllt sein:
    • Keine Textzeile darf länger als 998 Zeichen sein.
    • Mindestens ein Zeichen im Nachrichtentext hat einen Wert größer als 127.
    • Die Zeichen CR und LF können nur zusammen verwendet werden, um das Ende einer Textzeile anzuzeigen.

    Der gesamte Nachrichtentext kann 8 Bit oder ein Teil des Nachrichtentexts in einer mehrteiligen Nachricht 8 Bit sein. Enthält die multipart-Nachricht andere Teile mit Binärdaten, müssen diese Teile der Nachricht mit einem der Algorithmen „Quoted-printable" oder „Base64" codiert sein.

    Nachrichten mit 8-Bit-Textkörpern können nur zwischen SMTP-Messagingservern übertragen werden, die die in RFC 1652 definierte 8BITMIME-SMTP-Erweiterung unterstützen, z. B. Server mit Exchange 2000 Server oder neueren Versionen. Hierbei müssen insbesondere die folgenden Bedingungen erfüllt sein:

    • Das 8BITMIME -Schlüsselwort muss in der EHLO-Antwort des Servers angekündigt werden.
    • Nachrichten werden weiterhin unter Verwendung des SMTP-Standardbefehls DATA übermittelt. Der Parameter BODY=8BITMIME muss aber am Ende des MAIL FROM-Befehls hinzugefügt werden.
  • Binär: Dieser Wert gibt an, dass der Nachrichtentext Nicht-US-ASCII-Text oder Binärdaten enthält. Dies heißt insbesondere, dass die folgenden Bedingungen erfüllt sind:
    • Jede Zeichenfolge ist zulässig.
    • Es besteht keine Einschränkung der Zeilenlänge.
    • Binärnachrichtenelemente erfordern keine Codierung.

    Nachrichten mit binären Texten können nur zwischen SMTP-Messagingservern übertragen werden, die die SMTP-Erweiterung BINARYMIME gemäß RFC 3030 unterstützen, z. B. Server, auf denen Exchange 2000 Server oder neuere Versionen ausgeführt werden. Hierbei müssen insbesondere die folgenden Bedingungen erfüllt sein:

    • Das BINARYMIME -Schlüsselwort muss in der EHLO-Antwort des Servers angekündigt werden.
    • Die SMTP-Erweiterung BINARYMIME kann nur zusammen mit der SMTP-Erweiterung CHUNKING verwendet werden. Chunking ermöglicht das Senden von großen Nachrichtentexten in mehreren kleineren Teilstücken ("chunks"). Chunking ist ebenfalls in RFC 3030 definiert. Das CHUNKING -Schlüsselwort muss ebenfalls in der EHLO-Antwort des Servers angekündigt werden.
    • Nachrichten werden unter Verwendung des BDAT -Befehls anstelle des Standardbefehls DATA übermittelt.
    • Wenn die Nachricht über einen Nachrichtentext verfügt, muss der Parameter BODY=BINARYMIME am Ende des MAIL FROM-Befehls hinzugefügt werden.

Die Werte 7-Bit, 8-Bit und Binary sind nie zusammen in derselben mehrteiligen Nachricht vorhanden. Die Werte schließen sich gegenseitig aus. Die Werte in Anführungszeichen druckbar oder Base64 können in einem mehrteiligen 7-Bit- oder 8-Bit-Nachrichtentext angezeigt werden, aber nie in einem Binären Nachrichtentext. Wenn ein mehrteiliger Nachrichtentext verschiedene Teile enthält, die aus 7-Bit- und 8-Bit-Inhalten bestehen, wird die gesamte Nachricht als 8-Bit klassifiziert. Wenn ein mehrteiliger Nachrichtentext verschiedene Teile enthält, die aus 7-Bit-, 8-Bit- und Binärinhalten bestehen, wird die gesamte Nachricht als Binär klassifiziert.
Content-Disposition Attachment Dieses Kopfzeilenfeld, das in RFC 2183 beschrieben ist, teilt einem MIME-aktivierten E-Mail-Client mit, wie eine angefügte Datei angezeigt werden soll. Die Werte dieses Felds können Inline oder Attachment sein. Wenn der Wert dieses Felds Inline ist, wird die Anlage innerhalb des Nachrichtentexts angezeigt. Ist der Wert dieses Felds Attachment, wird die angefügte Datei als reguläre Anlage vom Nachrichtentext getrennt angezeigt. Wenn der Wert Attachment ist, sind noch andere Parameter verfügbar, wie z. B. Filename, Creation-date und Size.