Informationen zur Inhaltskonvertierung

 

Gilt für: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Letztes Änderungsdatum des Themas: 2009-09-09

Inhaltskonvertierung ist der Vorgang des richtigen Formatierens einer Nachricht für jeden Empfänger. Die Entscheidung, eine Inhaltskonvertierung für eine Nachricht durchzuführen, ist vom Ziel und Format der Nachricht abhängig, die verarbeitet wird. Nachrichten, die an Empfänger innerhalb der Microsoft Exchange Server-Organisation gesendet werden, benötigen keine Inhaltskonvertierung. Nur Nachrichten, die an externe Empfänger gesendet werden, bedürfen möglicherweise der Inhaltskonvertierung.

In einer Exchange Server 2007-Organisation wird die Inhaltskonvertierung vom Kategorisierungsmodul auf einem Server ausgeführt, auf dem die Serverfunktion Hub-Transport installiert ist. 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 die Inhaltskonvertierung die geeignete Codierung für jeden der Nachrichtenempfänger. Auf einem Edge-Transport-Server wird eine verkürzte Kategorisierung durchgeführt. An diesem Vorgang ist keine Inhaltskonvertierung beteiligt.

Informationen zum Aufbau von E-Mail-Nachrichten

Zum besseren Verständnis der Inhaltskonvertierung müssen Sie den Aufbau von E-Mail-Nachrichten kennen. Die Grundlage von SMTP (Simple Mail Transfer Protocol) bei der Erstellung und dem Senden von E-Mail-Nachrichten 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 nie zu Gesicht, weil er von dem Nachrichtenübertragungsprozess generiert wird und nicht tatsächlicher Bestandteil des Nachrichteninhalts ist.

  • Nachrichteninhalt   Der Nachrichteninhalt ist in RFC 2822 definiert. Er besteht aus folgenden Elementen:

    • Nachrichtenkopfzeile   Die Nachrichtenkopfzeile ist eine Sammlung von Kopfzeilenfeldern. Kopfzeilenfelder bestehen aus einem Feldnamen, gefolgt von einem Doppelpunkt (:), gefolgt von einem Feldtext und werden von einer Kombination aus Wagenrücklauf- und Zeilenvorschubzeichen (Carriage Return/Line Feed, CRLF) abgeschlossen.

      Ein Feldname muss aus druckbaren US-ASCII-Textzeichen bestehen, mit Ausnahme des Doppelpunkts (:). Insbesondere ASCII-Zeichen den Werten 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 CRLF enthalten, wenn sie beim Kopfzeilenumbruch ("folding") verwendet wird. Unter Kopfzeilenumbruch versteht man das Verteilen eines einzelnen Kopfzeilenfeldtexts auf mehrere Zeilen; eine Beschreibung des Verfahrens finden Sie in Abschnitt 2.2.3 von RFC 2822. Andere Anforderungen an die Feldtextsyntax werden in den Abschnitten 3 und 4 von RFC 2822 beschrieben.

    • Nachrichtentext   Der Nachrichtentext ist eine Sammlung von Zeilen aus US-ASCII-Textzeichen, die auf die Nachrichtenkopfzeile folgt. Die Nachrichtenkopfzeile und der Nachrichtentext sind durch eine Leerzeile getrennt, die durch die Zeichenkombination CRLF abgeschlossen ist. Der Nachrichtentext ist optional. Keine Textzeile im Nachrichtentext darf länger als 997 Zeichen sein. Die Zeichen CR und LF können nur zusammen verwendet werden, um das Ende einer Zeile anzuzeigen.

Wenn SMTP-Nachrichten Elemente enthalten, die kein unformatierter US-ASCII-Text sind, muss die Nachricht codiert werden, um diese Elemente zu erhalten. Der MIME-Standard definiert eine Methode zum Codieren von Nicht-Text-Inhalten in Nachrichten. MIME ermöglicht Text in anderen Zeichensätzen, Nicht-Text-Anlagen, mehrteilige Nachrichtentexte und Kopfzeilenfelder in anderen Zeichensätzen. MIME ist in RFC 2045, RFC 2046, RFC 2047, RFC 2048 und RFC 2077 definiert. MIME definiert eine Sammlung von Kopfzeilenfeldern, die zusätzliche Nachrichtenattribute angeben. In der folgenden Tabelle werden einige wichtige MIME-Kopfzeilenfelder beschrieben.

Wichtige MIME-Kopfzeilenfelder

Name des Kopfzeilenfelds Standardwert Beschreibung

MIME-Version:

1.0

Dieses Kopfzeilenfeld ist das erste MIME-Kopfzeilenfeld, das in einer Nachricht im MIME-Format vorkommt. Es folgt auf die anderen Standardkopfzeilenfelder gemäß RFC 2822, steht aber vor allen anderen MIME-Kopfzeilenfeldern. 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 Kopfzeilenfeld 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 keine Standardtypen. Untertypen, die mit "vnd." beginnen, sind herstellerspezifisch. Die IANA (Internet Assigned Names Authority) pflegt eine Liste der registrierten Medientypen. Weitere Informationen finden Sie unter MIME Media Types.

Hinweis

UNRESOLVED_TOKEN_VAL(exNote3rdPartyURL)

Der Medientyp multipart ermöglicht die Verwendung mehrerer Nachrichtenteile in derselben Nachricht, indem durch verschiedene Medientypen definierte Abschnitte verwendet werden. Mögliche Werte des Felds Content-Type: sind unter anderem "text/plain", "text/html", "multipart/mixed" und "multipart/alternative".

Content-Transfer-Encoding:

7bit

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 wurden.

  • Einen Indikator, der den aktuellen Zustand des Nachrichtentexts beschreibt.

Eine MIME-Nachricht kann mehrere Werte des Felds Content-Transfer-Encoding: enthalten. Wenn das Kopfzeilenfeld Content-Transfer-Encoding: in der Nachrichtenkopfzeile 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 Codieralgorithmus 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 Kopfzeilenfelds Content-Transfer-Encoding:, die anzeigen, dass ein Codieralgorithmus auf den Nachrichtentext angewendet wurde, sind folgende:

  • Quoted-printable   Dieser Codieralgorithmus verwendet druckbare US-ASCII-Zeichen zur Codierung der Nachrichtentextdaten. 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 Codieralgorithmus basiert in hohem Maß auf dem PEM-Standard (Privacy-Enhanced Mail), der in RFC 1421 definiert ist. Die Base64-Codierung verwendet den 64-Zeichenalphabet-Codieralgorithmus 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 Codieralgorithmus auf den Nachrichtentext angewendet wurde, zeig das Kopfzeilenfeld Content-Transfer-Encoding: nur den aktuellen Zustand der Nachrichtentextdaten an. Folgende Werte des Kopfzeilenfelds Content-Transfer-Encoding: zeigen an, dass kein Codieralgorithmus auf den Nachrichtentext angewendet wurde:

  • 7bit   Dieser Wert zeigt an, dass die Nachrichtentextdaten bereits im RFC 2822-Format sind. Hierbei müssen insbesondere die folgenden Bedingungen erfüllt sein:

    • Keine Textzeile darf länger als 997 Zeichen sein.

    • Alle Zeichen müssen US-ASCII-Text mit Zeichenwerten von 1 bis 127 sein.

    • Die Zeichen CR und LF können nur zusammen verwendet werden, um das Ende einer Textzeile anzuzeigen.

    Der gesamte Nachrichtentext oder ein Teil des Nachrichtentexts bei einer multipart-Nachricht (mehrteilig) kann 7bit 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 7bit-Texten können mithilfe des DATA-Standardbefehls zwischen SMTP-Messagingservern übermittelt werden.

  • 8bit   Dieser Wert zeigt 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 997 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 oder ein Teil des Nachrichtentexts bei einer multipart-Nachricht (mehrteilig) kann "8bit" 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 8bit-Texten können nur zwischen SMTP-Messagingservern übermittelt werden, die die 8BITMIME-SMTP-Erweiterung gemäß Definition in RFC 1652 unterstützen, z. B. Exchange 2000 Server oder höhere 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.

  • Binary   Dieser Wert zeigt an, dass der Nachrichtentext Nicht-US-ASCII-Zeichen 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 Binary-Texten können nur zwischen SMTP-Messagingservern übermittelt werden, die die BINARYMIME-SMTP-Erweiterung gemäß Definition in RFC 3030 unterstützen, z. B. Exchange 2000 oder höhere Versionen. 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 einen Nachrichtentext hat, muss der Parameter BODY=BINARYMIME am Ende des MAIL FROM-Befehls hinzugefügt werden.

Die Werte "7bit", "8bit" und "Binary" können nie gleichzeitig in derselben multipart-Nachricht vorkommen. Die Werte schließen sich gegenseitig aus. Die Werte "Quoted-printable" oder "Base64" können in einem 7bit- oder 8bit-multipart-Nachrichtentext (mehrteilig) vorkommen, aber nie in einem Binary-Nachrichtentext. Wenn ein multipart-Nachrichtentext (mehrteilig) verschiedene Teile enthält, die aus 7bit- und 8bit-Inhalten bestehen, wird die gesamte Nachricht als "8bit" klassifiziert. Wenn ein multipart-Nachrichtentext (mehrteilig) verschiedene Teile enthält, die aus 7bit-, 8bit- und Binary-Inhalten bestehen, wird die gesamte Nachricht als "Binary" 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".

Exchange 2007 und Outlook-Nachrichtenformate

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

  • Nur-Text   Eine Nur-Text-Nachricht verwendet ausschließlich US-ASCII-Text gemäß RFC 2822. 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.

    • Die Nachricht wird mit einem Content-Type-Wert von "text/plain" und einem Content-Transfer-Encoding-Wert von "7bit" für die Textteile einer multipart-Nachricht (mehrteilig) tatsächlich MIME-codiert. Alle Nachrichtenanlagen werden mit Quoted-printable- oder Base64-Codierung codiert. Beim Erstellen und Senden einer Nur-Text-Nachricht in Outlook wird die Nachricht standardmäßig mit einem Content-Type-Wert von "text/plain" tatsächlich MIME-codiert.

  • 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   RTF unterstützt Textformatierung und andere grafische Elemente. RTF ist gleichbedeutend mit TNEF (Transport Neutral Encoding Format). TNEF und RTF können identisch verwendet werden.

    Nur Outlook und einige wenige andere MAPI-E-Mail-Clients können RTF-Nachrichten interpretieren. MAPI ist eine von Microsoft entwickelte Messagingarchitektur, die mehreren Anwendungen die Interaktion mit verschiedenen Messagingsystemen auf einer Vielzahl verschiedener Hardwareplattformen ermöglicht. MAPI basiert auf der COM-Architektur (Component Object Model). Outlook verwendet MAPI für die Kommunikation mit Postfächern auf einem Computer, auf dem Exchange 2007 ausgeführt wird und auf dem die Serverfunktion Mailbox installiert ist.

    Das RTF-Nachrichtenformat unterscheidet sich grundlegend von dem in Microsoft Word verfügbaren RTF-Dokumentformat.

  • TNEF   TNEF 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:

    • Die formatierte Originalversion der Nachricht einschließlich beispielsweise Schriftarten, Textgrößen und Textfarben.

    • OLE-Objekte einschließlich z. B. eingebetteter Bilder oder eingebetteter Microsoft Office-Dokumente.

    • Spezielle Outlook-Features einschließlich z. B. benutzerdefinierter 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:

    • Eine RFC 2822-kompatible Nachricht, bestehend aus ausschließlich US-ASCII-Text.

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

    Ein MAPI-kompatibler E-Mail-Client, der TNEF vollständig interpretieren kann, wie z. B. Outlook, verarbeitet die Anlage Winmail.dat und zeigt den ursprünglichen Nachrichteninhalt an, ohne je die Anlage Winmail.dat 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 mit einem anderen allgemeinen Namen wie Attnnnnn**.dat** oder Attnnnnn**.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 können einige E-Mail-Clients wie Microsoft Outlook Express TNEF zwar möglicherweise nicht interpretieren, sind aber in der Lage TNEF-Anlagen zu erkennen und zu ignorieren. 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 Exchange Server 5.0 und höheren Versionen interpretiert. TNEF-Nachrichten werden unter Verwendung des Standardbefehls DATA zwischen SMTP-Messagingservern übermittelt. TNEF wird auf Grundlage der folgenden Situationen automatisch von Exchange verwendet:

    • Exchange 2000 Server   TNEF wird für Nachrichten verwendet, die zwischen Exchange-Servern übertragen werden, die sich in verschiedenen Routinggruppen befinden.

    • Exchange Server 2003   Wenn sich die Exchange-Organisation im gemischten Modus befindet, wird TNEF für Nachrichten verwendet, die zwischen Exchange-Servern übertragen werden, die sich in verschiedenen Routinggruppen befinden.

  • Summary Transport Neutral Encoding Format (STNEF)   STNEF ist mit TNEF äquivalent. STNEF-Nachrichten werden aber anders als TNEF-Nachrichten codiert. Insbesondere werden STNEF-Nachrichten immer MIME-codiert und haben immer einen Content-Transfer-Encoding-Wert von "Binary". Deshalb ist keine Nur-Text-Darstellung der Nachricht vorhanden, und im Text der Nachricht ist keine gesonderte Anlage Winmail.dat enthalten. Die gesamte Nachricht wird unter Verwendung von nur binären Daten dargestellt. Nachrichten, die einen Content-Transfer-Encoding-Wert von "Binary" haben, können nur zwischen SMTP-Messagingservern übertragen werden, die die SMTP-Erweiterungen BINARYMIME und CHUNKING gemäß der Definition in RFC 3030 unterstützen und ankündigen. Die Nachrichten werden zwischen SMTP-Messagingservern immer unter Verwendung des BDAT-Befehls anstelle des Standardbefehls DATA übermittelt.

    STNEF wird von Exchange 2000 und höheren Versionen interpretiert. STNEF wird unter folgenden Umständen automatisch von Exchange verwendet:

    • Exchange 2000   STNEF wird für Nachrichten verwendet, die zwischen Exchange-Servern übertragen werden, die sich in derselben Routinggruppe befinden. Ein nicht unterstützter Hotfix versetzt Exchange 2000 außerdem in die Lage, STNEF für Nachrichten zu verwenden, die zwischen Exchange-Servern in verschiedenen Routinggruppen übertragen werden.

    • Exchange 2003   Wenn sich die Exchange-Organisation im einheitlichen Modus befindet, wird STNEF für alle Nachrichten verwendet, die zwischen Exchange-Servern in der Organisation übertragen werden.

    • Exchange 2007   STNEF wird für alle Nachrichten verwendet, die zwischen Exchange-Servern in der Organisation übertragen werden.

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

Elemente der Inhaltskonvertierung

Inhaltskonvertierung ist der Vorgang des richtigen Formatierens einer Nachricht für jeden externen Empfänger. Diese Konvertierung wird vom Kategorisierungsmodul auf einem Hub-Transport-Server ausgeführt.

Die Inhaltskonvertierungsoptionen, die in einer Exchange-Organisation festgelegt werden können, können in folgende Kategorien untergliedert werden:

  • TNEF-Konvertierungsoptionen   Diese Konvertierungsoptionen geben an, ob TNEF in Nachrichten, die die Exchange-Organisation verlassen, erhalten bleiben oder daraus entfernt werden soll.

  • Nachrichtencodierungsoptionen   Diese Optionen geben Nachrichtencodierungsoptionen an, wie z. B. MIME- oder 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 2007-Organisation und Domänen außerhalb der Active Directory-Verzeichnisdienst-Gesamtstruktur. Auch wenn für bestimmte Domänen keine Remotedomäneneinträge erstellt werden, ist eine vordefinierte Remotedomäne namens Standard vorhanden, die Anwendung auf alle Remoteadressräume (*) Anwendung findet.

  • E-Mail-Benutzer- und E-Mail-Kontakteinstellungen   E-Mail-Benutzer ähneln E-Mail-Kontakten – beide besitzen externe E-Mail-Adressen und enthalten Informationen über Personen außerhalb der Exchange-Organisation. Der Hauptunterschied besteht darin, dass E-Mail-Benutzer Sicherheitskontexte besitzen, die für die Anmeldung an der Active Directory-Domäne verwendet werden können, und auf Ressourcen zugreifen können, für die Ihnen Berechtigungen erteilt wurden.

  • Outlook-Einstellungen   In Outlook können Sie die in der folgenden Liste beschriebenen Nachrichtenformatierungs- und -codierungsoptionen 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.

    • Internet-Nachrichtenformat   Sie können steuern, ob TNEF-Nachrichten direkt an Remoteempfänger gesendet werden, oder ob sie zuerst in ein besser kompatibles 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 innerhalb der Exchange-Organisation gesendet werden.

    • Nachrichtenformat für Internet-Empfänger   Sie können steuern, ob TNEF-Nachrichten direkt an bestimmte Empfänger gesendet werden, oder ob sie zuerst in ein besser kompatibles Format konvertiert werden. Die Konvertierungsoptionen können für bestimmte Kontakte im Ordner Kontakte festgelegt werden. Beim Erstellen einer Nachricht können Sie diese Konvertierungsoptionen dann für einen bestimmten Empfänger in einem der Felder An:, Cc: oder Bcc: außer Kraft setzen. Diese Konvertierungsoptionen sind für Empfänger innerhalb der Exchange-Organisation nicht verfügbar.

    • Nachrichtencodierungsoptionen für Internet-Empfänger   Sie können die MIME- oder Nur-Text-Codierungsoptionen für bestimmte Kontakte im Ordner Kontakte steuern. Beim Erstellen einer Nachricht können Sie diese Konvertierungsoptionen dann für einen bestimmten Empfänger in einem der Felder An:, Cc: oder Bcc: außer Kraft setzen. Diese Konvertierungsoptionen sind für Empfänger innerhalb der Exchange-Organisation nicht verfügbar.

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

TNEF-Konvertierungsoptionen

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

  • Remotedomäneneinstellungen

  • E-Mail-Benutzer- und E-Mail-Kontakteinstellungen

  • Outlook-Einstellungen

    • Nachrichtenformat

    • Internet-Nachrichtenformat

    • Nachrichtenformat für Internetempfänger

Ausführliche Informationen finden Sie unter TNEF-Konvertierungsoptionen.

Nachrichtencodierungsoptionen

Sie können die Nachrichtencodierungsoptionen auf folgenden Ebenen angeben:

  • Remotedomäneneinstellungen

  • E-Mail-Benutzer- und E-Mail-Kontakteinstellungen

  • Outlook-Einstellungen

    • Nachrichtenformat

    • Internetnachricht

    • Nachrichtenformat für Internetempfänger

    • Nachrichtenzeichensatz-Codierungsoptionen

Ausführliche Informationen finden Sie unter Nachrichtencodierungsoptionen.

Inhaltskonvertierung durch den Informationsspeichertreiber

Der Informationsspeichertreiber führt ebenfalls eine Art der Inhaltskonvertierung aus. Der Informationsspeichertreiber ist auf Hub-Transport-Servern vorhanden, um Nachrichten zwischen Postfächern auf Postfachservern und der Übermittlungswarteschlange zu transportieren. Der Informationsspeichertreiber transportiert insbesondere Nachrichten aus dem Postausgang des Absenders zur Übermittlungswarteschlange auf dem Hub-Transport-Server sowie die Nachrichten von der MAPI-Zustellungswarteschlange auf dem Hub-Transport-Server an den Posteingang des Empfängers. Der Informationsspeichertreiber konvertiert alle ausgehenden Nachrichten aus MAPI und alle eingehenden Nachrichten in MAPI. Die Ablaufverfolgung für die Inhaltskonvertierung erfasst diese Informationsspeicher-Konvertierungsfehler.

Weitere Informationen finden Sie unter Verwalten der Ablaufverfolgung für die Inhaltskonvertierung.