コンテンツ変換について

 

適用先: Exchange Server 2010 SP2, Exchange Server 2010 SP3

トピックの最終更新日: 2016-11-28

コンテンツ変換は、各受信者に合わせてメッセージの書式を正しく設定するプロセスです。メッセージに対してコンテンツ変換を実行するかどうかの判断は、処理中のメッセージの送信先および書式に基づきます。Microsoft Exchange Server 組織内の受信者に送信されるメッセージには、コンテンツ変換は不要です。外部の受信者に送信されるメッセージのみ、コンテンツ変換が必要になる可能性があります。

Exchange Server 2010 組織では、コンテンツ変換は、ハブ トランスポート サーバーの役割がインストールされているサーバー上のカテゴライザーによって処理されます。各メッセージの分類は、新着メッセージが送信キューに置かれた後で実行されます。メッセージに対して受信者の解決およびルーティングの解決、およびコンテンツ変換が実行されると、そのメッセージは配信キューに置かれます。1 つのメッセージに複数の受信者が含まれている場合は、コンテンツ変換によって各メッセージ受信者に適切なエンコーディングが指定されます。エッジ トランスポート サーバー上では、コンテンツ変換を含まない省略された分類が行われます。

目次

電子メール メッセージの構造について

Exchange 2010 および Outlook のメッセージ形式

コンテンツ変換の要素

ストア ドライバーによって実行されるコンテンツ変換

コンテンツ変換に関連する管理タスクについては、「トランスポート サーバーの管理」を参照してください。

電子メール メッセージの構造について

コンテンツ変換についての理解を深めるには、電子メール メッセージの構造を理解する必要があります。SMTP メッセージは、電子メール メッセージを作成して送信するための 7 ビットの US-ASCII テキストを基礎にしています。標準的な SMTP メッセージは、次の要素で構成されます。

  • メッセージ エンベロープ   メッセージ エンベロープは RFC 2821 で定義されます。メッセージ エンベロープには、メッセージの転送と配信に必要な情報が含まれています。メッセージ エンベロープはメッセージ送信プロセスによって生成されるものであり、実際にはメッセージ コンテンツの一部ではないため、受信者がメッセージ エンベロープを目にすることはありません。

  • メッセージのコンテンツ   メッセージのコンテンツは RFC 2822 で定義されています。メッセージのコンテンツは、次の要素で構成されます。

    • メッセージ ヘッダー   メッセージ ヘッダーはヘッダー フィールドの集合です。ヘッダー フィールドには、フィールド名、コロン (:) 文字、フィールド本体が順に含まれており、最後に改行コード (CR/LF) 文字の組み合わせが含まれています。

      フィールド名は、コロン (:) 文字を除く印刷可能な US-ASCII テキスト文字で構成する必要があります。具体的には、ASCII コード 33 ~ 57 および 59 ~ 126 の値の文字を使用できます。

      フィールド本体は、改行コード (CR/LF) 文字以外の印刷可能な US-ASCII テキスト文字で構成する必要があります。ただし、ヘッダーフォールディングで使用される場合は、フィールド本体に CR/LF 文字の組み合わせが含まれる可能性があります。ヘッダー フォールディングとは、RFC 2822 のセクション 2.2.3 で示されているように、1 つのヘッダーを複数行に分けることです。他のフィールド本体の構文の要件については、RFC 2822 のセクション 3 および 4 に示されています。

    • メッセージ本文   メッセージ本文は、メッセージ ヘッダーの後に表示される US-ASCII テキスト文字の行の集合です。メッセージ ヘッダーおよびメッセージ本文は、末尾に CR/LF 文字の組み合わせが付く空白行で区切られます。メッセージ本文はオプションです。メッセージ本文のテキストの行は、998 文字以下である必要があります。CR および LF 文字は、行の終わりを表すために、常に組み合わせて使用されます。

SMTP メッセージに US-ASCII テキスト形式ではない要素が含まれている場合、それらの要素を保持するためにはメッセージをエンコードする必要があります。MIME 標準は、メッセージ内のテキスト形式ではないコンテンツのエンコード方法を定義します。MIME により、他の文字セットによるテキスト、テキストのない添付ファイル、マルチパート メッセージの本文、および他の文字セットによるヘッダー フィールドが可能になります。MIME は RFC 2045、RFC 2046、RFC 2047、RFC 2048、および RFC 2077 で定義されています。MIME は、追加のメッセージの属性を指定するヘッダー フィールドの集合を定義します。次の表は、一部の重要な MIME ヘッダー フィールドの説明です。

重要な MIME ヘッダー フィールド

ヘッダー フィールド名 既定値 説明

MIME-Version

1.0

このヘッダー フィールドは、MIME 形式のメッセージに表示される最初の MIME ヘッダー フィールドです。このヘッダー フィールドは、他の標準 RFC 2822 ヘッダー フィールドの後に表示されますが、他のすべての MIME ヘッダー フィールドの前に表示されます。MIME 対応の電子メール クライアントは、このヘッダー フィールドを使用して MIME エンコード メッセージを識別します。このヘッダー フィールドが存在しない場合、MIME 対応の電子メール クライアントはメッセージをテキスト形式と認識します。

Content-Type

text/plain

このヘッダー フィールドは、RFC 2046 の記述に基づいてメッセージ コンテンツのメディアの種類を定義します。メディアの種類は、タイプ、サブタイプのほか、MIME 文字エンコーディングを定義する charset= パラメーターなどの 1 つ以上のオプション パラメーターで構成されます。「x-」で始まる種類は標準ではありません。「vnd.」で始まるサブタイプはベンダーに固有のものです。IANA (Internet Assigned Numbers Authority) が、登録されているメディアの種類の一覧を管理しています。詳細については、MIME メディアの種類に関するページを参照してください (このサイトは英語の場合があります)。

マルチパートのメディアの種類により、複数のメディアの種類で定義されるセクションを使用して、同じメッセージ内に複数のメッセージ部分が存在できるようになります。一部の Content-Type フィールド値には、text/plain、text/html、multipart/mixed、および multipart/alternative があります。

Content-Transfer-Encoding

7bit

このヘッダー フィールドでは、メッセージに関する次の情報を記述できます。

  • メッセージ本文に存在する US-ASCII 形式ではないテキストまたはバイナリ データの変換に使用したエンコーティングのアルゴリズム。

  • メッセージ本文の現在の条件を示す指標。

MIME メッセージの Content-Transfer-Encoding ヘッダー フィールドには、複数の値が存在する可能性があります。Content-Transfer-Encoding ヘッダー フィールドがメッセージ ヘッダー内にある場合は、それがメッセージ本文全体に適用されます。Content-Transfer-Encoding ヘッダー フィールドがマルチパート メッセージのパートの 1 つにある場合は、メッセージのその部分のみに適用されます。

エンコーディングのアルゴリズムがメッセージ本文のデータに適用される場合、メッセージ本文のデータは US-ASCII テキスト形式に変換されます。この変換により、メッセージは、US-ASCII テキスト形式のメッセージのみをサポートしている古い SMTP メッセージング サーバーを通過できるようになります。Content-Transfer-Encoding ヘッダー フィールドの値は、次のようにメッセージ本文に対して使用されたエンコーディングのアルゴリズムを示しています。

  • Quoted-printable   このエンコーディングのアルゴリズムは、印刷可能な US-ASCII 文字列を使用してメッセージ本文のデータをエンコードします。元のメッセージ テキストの大部分が US-ASCII テキストである場合は、Quoted-printable エンコーディングによってある程度判読できる小サイズの結果が得られます。等号 (=) 文字を除くすべての印刷可能な US-ASCII テキスト形式の文字は、エンコーディングを行わなくても表すことができます。

  • Base64   このエンコーディングのアルゴリズムは、主に、RFC 1421 で定義されている PEM (Privacy-Enhanced Mail) 標準に基づいています。Base64 エンコーディングでは、PEM で定義されている 64 文字のアルファベットのエンコーディング アルゴリズムと出力スペース文字を使用して、メッセージ本文のデータをエンコードします。Base64 エンコード メッセージのサイズは通常、元のメッセージよりも 33% 大きくなります。Base64 エンコードは、メッセージのサイズがどの程度増えるかを予測できるため、バイナリ データおよび US-ASCII 形式ではないテキストに最適です。

通常、1 つのメッセージ内に使用される複数のエンコーディング アルゴリズムは表示されません。

メッセージ本文でエンコーディングのアルゴリズムが使用されていない場合、Content-Transfer-Encoding ヘッダー フィールドは、メッセージ本文データの現在の状態のみを識別します。次の Content-Transfer-Encoding ヘッダー フィールドの値は、メッセージ本文に対してエンコーディングのアルゴリズムが使用されていないことを示しています。

  • 7bit   この値は、メッセージ本文のデータが既に RFC 2822 形式になっていることを示しています。具体的には、次の条件が満たされている必要があることを意味しています。

    • テキストのすべての行は 998 文字以下にする必要があります。

    • すべての文字が US-ASCII 1 ~ 127 の範囲の文字によるテキスト形式である必要があります。

    • CR および LF 文字は、テキスト行の末尾を表すために、常に組み合わせて使用されます。

    メッセージ全体が 7bit であるか、マルチパート メッセージのメッセージ本文の一部が 7bit である可能性があります。マルチパート メッセージの他の部分に、バイナリ データまたは US-ASCII 形式ではないテキストが含まれている場合、メッセージのその部分は Quoted-printable または Base64 のエンコーディング アルゴリズムを使用してエンコードする必要があります。

    7bit の本文を持つメッセージは、標準 DATA コマンドを使用して SMTP メッセージング サーバー間を転送することができます。

  • 8bit   この値は、メッセージ本文のデータが US-ASCII 形式ではない文字を含んでいることを示しています。具体的には、次の条件が満たされている必要があることを意味しています。

    • テキストのすべての行は 998 文字以下にする必要があります。

    • メッセージ本文の 1 つ以上の文字の値が 127 を超えています。

    • CR および LF 文字は、テキスト行の末尾を表すために、常に組み合わせて使用されます。

    メッセージ全体が 8bit であるか、マルチパート メッセージのメッセージ本文の一部が 8bit である可能性があります。マルチパート メッセージの他の部分にバイナリ データが含まれている場合、メッセージのその部分は Quoted-printable または Base64 のエンコーディング アルゴリズムを使用してエンコードする必要があります。

    本文が 8bit のメッセージは、Exchange 2010、Exchange Server 2007、Exchange Server 2003、または Exchange 2000 Server を実行しているサーバーなどの、RFC 1652 の定義に従って 8BITMIME SMTP 拡張をサポートしている SMTP メッセージング サーバー間のみを転送できます。具体的には、次の条件が満たされている必要があることを意味しています。

    • サーバーの EHLO 応答では、8BITMIME キーワードを宣言する必要があります。

    • この場合でも、メッセージは SMTP 標準の DATA コマンドを使用して転送されます。ただし、BODY=8BITMIME パラメーターを MAIL FROM コマンドの最後に追加する必要があります。

  • Binary   この値は、メッセージ本文に US-ASCII 形式ではないテキストまたはバイナリ データが含まれていることを示しています。具体的には、次の条件が満たされていることを意味しています。

    • 任意の文字列が許可されます。

    • 行の長さに制限はありません。

    • バイナリ メッセージ要素には、エンコーディングは不要です。

    バイナリ本文のメッセージは、Exchange 2010、Exchange 2007、Exchange 2003、または Exchange 2000 を実行しているサーバーなどの、RFC 3030 の定義に従って BINARYMIME SMTP 拡張をサポートしている SMTP メッセージング サーバー間のみを転送できます。具体的には、次の条件が満たされている必要があることを意味しています。

    • サーバーの EHLO 応答では、BINARYMIME キーワードを宣言する必要があります。

    • BINARYMIME SMTP 拡張は、必ず CHUNKING SMTP 拡張と共に使用する必要があります。チャンキングを使用すると、大きなメッセージ本文を複数の小さなチャンクに分けて送信することができます。チャンキングは、RFC 3030 でも定義されています。サーバーの EHLO 応答で CHUNKING キーワードを宣言する必要があります。

    • メッセージは、標準 DATA コマンドの代わりに BDAT コマンドを使用して転送されます。

    • メッセージにメッセージ本文が含まれている場合は、MAIL FROM コマンドの最後に BODY=BINARYMIME パラメーターを追加する必要があります。

7bit、8bit、および Binary の値は、同じマルチパート メッセージ内に同時に存在することはできません。これらの値は同時に使用することができません。値 Quoted-printable または Base64 は、7bit または 8bit のマルチパートのメッセージ本文では使用できますが、Binary メッセージ本文には使用できません。マルチパート メッセージ本文に 7bit および 8bit のコンテンツで構成される複数の部分が含まれている場合、メッセージ全体は 8bit に分類されます。マルチパート メッセージ本文に 7bit、8bit、および Binary のコンテンツで構成される複数の部分が含まれている場合、メッセージ全体は Binary に分類されます。

Content-Disposition

Attachment

このヘッダー フィールドは、RFC 2183 で定義されているとおりに、MIME が有効な電子メール クライアントに添付ファイルの表示方法に関する指示を与えます。このフィールドの値は、Inline または Attachment です。このフィールドの値が Inline である場合、添付ファイルはメッセージ本文に表示されます。このフィールドの値が Attachment である場合、添付ファイルはメッセージ本文から分離された通常の添付ファイルとして表示されます。値が Attachment である場合、Filename、Creation-date、Size Attachment などの他のパラメーターを使用できます。

Exchange 2010 および Outlook のメッセージ形式

次の一覧は、Exchange 2010 および Microsoft Outlook で使用できる基本的なメッセージ形式を示しています。

  • テキスト形式   プレーンなテキスト形式のメッセージは、RFC 2822 で説明されているように US-ASCII 形式のテキストのみを使用します。このメッセージには、複数のフォントなどのテキスト書式を含めることはできません。テキスト形式のメッセージには、次の 2 つの書式を使用できます。

    • メッセージ ヘッダーとメッセージ本文は、US-ASCII 形式のテキストで構成されます。添付ファイルは、UUEncode を使用してエンコードする必要があります。UUEncode は Unix-to-Unix encoding を意味し、US-ASCII 形式のテキスト文字を使用することによってバイナリ形式の添付ファイルを電子メール メッセージの本文に保存するエンコーディング アルゴリズムを定義します。

    • メッセージは、text/plain の Content-Type 値、およびマルチパート メッセージのテキスト部分の場合は 7bit の Content-Transfer-Encoding 値を使用して、MIME でエンコードされます。メッセージ添付ファイルがある場合は、Quoted-printable または Base64 エンコーディングを使用してエンコードされます。既定では、Outlook でテキスト形式のメッセージを作成して送信する場合、メッセージは text/plain の Content-Type 値を使用して MIME でエンコードされます。

  • HTML   HTML メッセージは、テキストの書式、背景の画像、表、箇条書き、その他のグラフィック要素をサポートしています。定義により、HTML 形式のメッセージは、これらの書式の要素が維持されるように MIME でエンコードする必要があります。

  • リッチ テキスト形式 (RTF)   RTF は、テキストの書式と他のグラフィック要素をサポートしています。RTF は TNEF (Transport Neutral Encapsulation Format) の同義語です。TNEF と RTF は、同じ意味で使用することができます。

    RTF メッセージを認識できるのは、Outlook、および他のいくつかの MAPI 電子メール クライアントのみに限られます。MAPI は、Microsoft によって開発された、複数のアプリケーションがさまざまなハードウェア プラットフォームで動作する異なるメッセージング システムと相互運用できるようにするためのメッセージング アーキテクチャです。MAPI は、コンポーネント オブジェクト モデル (COM) アーキテクチャ上に構築されます。Outlook は MAPI を使用して、メールボックス サーバーの役割がインストールされ、Exchange 2010 が動作しているコンピューター上のメールボックスと通信します。

    リッチ テキストのメッセージ形式は、Microsoft Word で使用できるリッチ テキストのドキュメント形式とはまったく異なります。

  • TNEF   TNEF は、MAPI メッセージ プロパティをカプセル化する Microsoft 固有の形式です。TNEF メッセージには、テキスト形式のメッセージと、元の書式のメッセージをパッケージ化した添付ファイルが含まれています。この添付ファイルの名前は通常、Winmail.dat です。Winmail.dat 添付ファイルには、次の情報が含まれています。

    • フォント、テキスト サイズ、テキストの色などの元の書式のメッセージ。

    • 埋め込まれた画像や埋め込まれた MicrosoftOffice 文書など OLE オブジェクト。

    • 特別な Outlook 機能として、カスタム フォーム、投票ボタン、および会議出席依頼など。

    • 元のメッセージ内にあった通常のメッセージの添付ファイル。

    生成されるテキスト形式のメッセージは、次の形式で表すことができます。

    • UUEncode でエンコードされた Winmail.dat 添付ファイルを含む、US-ASCII テキストのみで構成されている RFC 2822 準拠のメッセージ。

    • Winmail.dat 添付ファイルを含む、マルチパートの MIME でエンコードされたメッセージ。

    Outlook などの完全に TNEF を認識する MAPI 準拠の電子メール クライアントは、Winmail.dat 添付ファイルを処理して、Winmail.dat 添付ファイルを表示することなく、元のメッセージのコンテンツを表示します。TNEF を認識しない電子メール クライアントは、次の方法で TNEF メッセージを表示することができます。

    • テキスト形式のメッセージが表示され、そのメッセージには Winmail.dat、Win.dat、または他の一般的な名前 (Attnnnnn.dat、Attnnnnn.eml など) の添付ファイルが含まれます。ここで、nnnnn プレースホルダーは乱数を表します。

    • テキスト形式のメッセージが表示されます。TNEF 添付ファイルは、無視されるか削除されます。その結果、テキスト形式のメッセージになります。

    • TNEF を認識するメッセージング サーバーは、TNEF 添付ファイルを受信メッセージから削除するように構成することができます。その結果、テキスト形式のメッセージになります。さらに、Microsoft などの一部の電子メール クライアントは、TNEF を認識することはできませんが TNEF 添付ファイルは認識して無視します。その結果、テキスト形式のメッセージになります。

    サード パーティのユーティリティが Winmail.dat 添付ファイルの変換に役立つことがあります。

    TNEF は、Exchange 2010、Exchange 2007、Exchange 2003、Exchange 2000、および Exchange Server Version 5.5 で認識されます。TNEF メッセージは、SMTP メッセージング サーバー間で標準の DATA コマンドによって転送されます。TNEF は、次の条件に基づいて Exchange によって自動的に使用されます。

    • Exchange 2003   Exchange 組織が混在モードの場合、TNEF は、異なるルーティング グループに所属する Exchange サーバー間で転送されるメッセージに使用されます。

    • Exchange 2000   TNEF は、異なるルーティング グループに所属する Exchange サーバー間で転送されるメッセージに使用されます。

  • STNEF (Summary Transport Neutral Encapsulation Format)   STNEF は TNEF と同じです。ただし、STNEF メッセージは TNEF メッセージとは別にエンコードされます。具体的には、STNEF メッセージは常に MIME でエンコードされ、Content-Transfer-Encoding 値は常に Binary になります。したがって、テキスト形式で表現されたメッセージはなく、独立した Winmail.dat 添付ファイルがメッセージ本文に含まれることはありません。メッセージ全体は、バイナリ データのみを使用して表されます。Content-Transfer-Encoding 値が Binary であるメッセージは、RFC 3030 で定義されているように、BINARYMIME および CHUNKING SMTP 拡張をサポートして通知する SMTP メッセージング サーバー間のみで転送することができます。メッセージは常に、標準 DATA コマンドの代わりに BDAT コマンドを使用して、SMTP メッセージング間で転送されます。

    STNEF は、Exchange 2010、Exchange 2007、Exchange 2003、および Exchange 2000 で認識されます。次の条件が満たされる場合、STNEF は Exchange によって自動的に使用されます。

    • Exchange 2010   組織内の Exchange サーバー間で転送されるすべてのメッセージに STNEF が使用されます。

    • Exchange 2007   組織内の Exchange サーバー間で転送されるすべてのメッセージに STNEF が使用されます。

    • Exchange 2003   Exchange 組織がネイティブ モードの場合、組織内の Exchange サーバー間で転送されるすべてのメッセージに STNEF が使用されます。

    • Exchange 2000   STNEF は、同じルーティング グループに所属する Exchange サーバー間で転送されるメッセージに使用されます。また、Exchange 2000 は、サポートされていない修正プログラムにより、異なるルーティング グループの Exchange サーバー間で転送されるメッセージに STNEF を使用できるようになります。

    Exchange は、STNEF メッセージを外部の受信者に送信しません。Exchange 組織外の受信者に送信できるのは、TNEF メッセージだけです。

コンテンツ変換の要素

コンテンツ変換では、各外部受信者に合わせてメッセージの書式を正しく設定します。この変換は、ハブ トランスポート サーバーのカテゴライザーによって実行されます。

Exchange 組織で設定できるコンテンツ変換オプションは、次のカテゴリに分けられます。

  • TNEF 変換オプション   これらの変換オプションは、Exchange 組織から送信されるメッセージ内の TNEF を維持するか削除するかを指定します。

  • メッセージ エンコーディング オプション   これらのオプションは、MIME および非 MIME 文字セット、メッセージ エンコーディング、添付ファイル形式などのメッセージ エンコーディング オプションを指定します。

これらの変換およびコーディング オプションには、相互の依存関係はありません。たとえば、TNEF メッセージを Exchange 組織の外に送信できるかどうかは、それらのメッセージの MIME エンコーディング設定やテキスト形式のエンコーディング設定とは関係ありません。

次の一覧で示されているように、Exchange 組織のさまざまなレベルでコンテンツ変換を指定できます。

  • リモート ドメイン設定   リモート ドメインは、Exchange 2010 組織と Active Directory フォレスト外のドメインの間で転送される送信メッセージの設定を定義します。特定のドメインのリモート ドメイン エントリを作成しない場合でも、Default という名前の付いたリモート ドメインが事前に定義されており、すべてのリモート アドレス スペース (*) に適用されます。

  • メール ユーザーおよびメール連絡先設定   メール ユーザーはメール連絡先に似ています。どちらも外部電子メール アドレスを持ち、Exchange 組織外の人に関する情報が含まれています。主な違いは、メールユーザーが Active Directory ドメインへのログオンおよびアクセス権が付与されているリソースへのアクセスに使用できるセキュリティ コンテキストを持っていることです。

  • Outlook の設定   Outlook では、次の一覧に示されている書式設定およびエンコーディング オプションをメッセージに対して設定できます。

    • メッセージ形式   すべてのメッセージに既定のメッセージ形式を設定できます。特定のメッセージを作成する際に既定のメッセージ形式を上書きできます。

    • インターネット メッセージ形式   リモートの受信者に TNEF メッセージを送信するか、またはあらかじめ互換性の高い形式に変換するかを制御できます。また、リモートの受信者に送信するメッセージに対して、各種メッセージ エンコーディング オプションを指定できます。これらの設定は、Exchange 組織の受信者に送信するメッセージには適用されません。

    • インターネット受信者のメッセージ形式   特定の受信者に TNEF メッセージを送信するか、またはあらかじめ互換性の高い形式に変換するかを制御できます。連絡先フォルダーの特定の連絡先に変換オプションを設定できます。また、メッセージを作成する際に、宛先、CC、または BCC フィールドにおける特定の受信者の変換オプションを上書きできます。これらの変換オプションは、Exchange 組織の受信者には使用できません。

    • インターネット受信者のメッセージ エンコーディング オプション   連絡先フォルダーの特定の連絡先に対する MIME またはテキスト形式のエンコーディング オプションを制御できます。また、メッセージを作成する際に、宛先、CC、または BCC フィールドにおける特定の受信者の変換オプションを上書きできます。これらの変換オプションは、Exchange 組織の受信者には使用できません。

    • 国際オプション   メッセージに使用する文字セットを制御できます。

TNEF 変換オプション

次のレベルで TNEF 変換オプションを指定できます。

  • リモート ドメインの設定

  • メール ユーザーおよびメール連絡先設定

  • Outlook 設定には以下が含まれます。

    • メッセージ形式

    • インターネット メッセージ形式

    • インターネット受信者のメッセージ形式

詳細情報については、「TNEF 変換オプション」を参照してください。

メッセージ エンコーディング オプション

次のレベルでメッセージ オプションを指定できます。

  • リモート ドメインの設定

  • メール ユーザーおよびメール連絡先設定

  • Outlook 設定には以下が含まれます。

    • メッセージ形式

    • インターネット メッセージ

    • インターネット受信者のメッセージ形式

    • メッセージ文字セットのエンコーディング オプション

詳細情報については、「メッセージ エンコーディング オプション」を参照してください。

ストア ドライバーによって実行されるコンテンツ変換

ストア ドライバーもコンテンツ変換を実行します。ストア ドライバーはハブ トランスポート サーバー上にあり、メールボックス サーバーおよび送信キュー上にあるメールボックス間でメッセージを転送します。具体的には、ストア ドライバーは送信者の送信トレイからハブ トランスポート サーバー上にある送信キューにメッセージを転送し、ハブ トランスポート サーバー上にある送信キューから受信者の受信トレイにメッセージを転送します。ストア ドライバーは、MAPI からすべての送信メッセージを変換し、すべての受信メッセージを MAPI に変換します。コンテンツ変換のトレースでは、これらのストア ドライバー変換のエラーがキャプチャされます。

詳細については、「コンテンツ変換トレース」を参照してください。

 © 2010 Microsoft Corporation.All rights reserved.