次の方法で共有

コンテンツ変換

  • [アーティクル]

製品: Exchange Server 2013

コンテンツ変換は、各受信者に合わせてメッセージの書式を正しく設定するプロセスです。 メッセージに対してコンテンツ変換を実行する決定は、処理されるメッセージの宛先と形式によって異なります。 Microsoft Exchange Server 2013 では、次の 2 種類のコンテンツ変換があります。

  • 外部受信者のメッセージ変換: この種類のコンテンツ変換には、トランスポートニュートラル カプセル化形式 (TNEF) 変換オプションと、外部受信者のメッセージ エンコード オプションが含まれます。 Exchange 組織内の受信者に送信されるメッセージには、この種類のコンテンツ変換は不要です。 この種類のコンテンツ変換は、メールボックス サーバー上のトランスポート サービスのカテゴライザーによって処理されます。 各メッセージの分類は、新着メッセージが送信キューに置かれた後で実行されます。 メッセージに対して受信者の解決およびルーティングの解決、およびコンテンツ変換が実行されると、そのメッセージは配信キューに置かれます。 1 つのメッセージに複数の受信者が含まれている場合は、カテゴライザーによって各メッセージ受信者に適切なエンコーディングが指定されます。 コンテンツ変換トレースでは、外部の受信者に送信されたメッセージの変換時に、カテゴライザーが検出したコンテンツ変換エラーはキャプチャされません。

  • 内部受信者の MAPI 変換: この種類のコンテンツ変換は、メールボックス トランスポート サービスによって処理されます。 特に、メールボックス トランスポート発信サービスは、送信者の送信トレイからメールボックス サーバー上のトランスポート サービスにメッセージを送信します。 メールボックス トランスポート配信サービスは、メールボックス サーバー上のトランスポート サービスから受信者の受信トレイにメッセージを送信します。 メールボックス トランスポート発信サービスは、すべての送信メッセージを MAPI から変換します。 メールボックス トランスポート配信サービスは、すべての受信メッセージを MAPI に変換します。 コンテンツ変換のトレースでは、これらの MAPI 変換のエラーがキャプチャされます。 詳細については、「 コンテンツ変換トレース」を参照してください。

このトピックでは、外部受信者のメッセージ変換オプションについて説明します。

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

次の一覧では、Exchange と 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 でプレーン テキスト メッセージを作成して送信すると、メッセージはテキスト/プレーンの Content-Type 値で MIME エンコードされます。

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

  • リッチ テキスト形式 (RTF): RTF では、テキストの書式設定やその他のグラフィカル要素がサポートされています。 RTF は TNEF と同義です。 TNEF と RTF は同じ意味で使用できます。 リッチ テキスト メッセージ形式は、Microsoft Word で使用できるリッチ テキスト ドキュメント形式とは完全に異なります。

    RTF メッセージを理解できるのは、Outlook とその他の MAPI 電子メール クライアントのみです。

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

    • フォント、テキスト サイズ、テキストの色など、メッセージの元の書式設定されたバージョン

    • 埋め込み図や埋め込み Microsoft Office ドキュメントなどの OLE オブジェクト

    • カスタム フォーム、投票ボタン、会議出席依頼など、Outlook の特殊な機能

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

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

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

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

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

    • メッセージのプレーン テキスト バージョンが表示され、メッセージには Winmail.dat、Win.dat、または nnnnn プレースホルダーが乱数を表す Att_nnnnn_.dat や Att_nnnnn_.eml などの他のジェネリック名という名前の添付ファイルが含まれています。

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

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

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

      TNEF は、Exchange Server Version 5.5 以降のすべてのバージョンの Exchange で認識できます。

  • 概要トランスポートニュートラル カプセル化形式 (STNEF): 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 2000 以降のすべてのバージョンの Exchange で認識できます。 STNEF は、ネイティブ モード Exchange Server 2003 以降の組織内の Exchange サーバー間で転送されるすべてのメッセージに自動的に使用されます。

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

外部の受信者に対するコンテンツの変換オプション

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

  • TNEF 変換オプション: これらの変換オプションは、Exchange 組織を離れるメッセージに対して TNEF を保持するか削除するかを指定します。

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

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

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

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

  • メール ユーザーとメール連絡先の設定: メール ユーザーとメール連絡先の両方に外部のメール アドレスがあり、Exchange 組織外のユーザーに関する情報が含まれているため、似ています。 主な違いは、メール ユーザーが Active Directory ドメインにログオンし、組織内のリソースにアクセスするために使用できるアカウントを持っていることです。

  • Outlook の設定: Outlook では、次の一覧で説明するメッセージの書式設定とエンコード オプションを設定できます。

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

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

    • インターネット受信者メッセージ形式: TNEF メッセージを特定の受信者に送信するかどうか、または最初に互換性のある形式に変換するかどうかを制御できます。 連絡先フォルダー内の特定の連絡先の変換オプションを設定できます。また、メッセージを作成するときに、[宛先]、[Cc]、または [Bcc] フィールドの特定の受信者の変換オプションをオーバーライドできます。 Exchange 組織の受信者は、これらのオプションを使用できません。

    • インターネット受信者メッセージ エンコード オプション: 連絡先フォルダー内の特定の連絡先の MIME またはプレーン テキスト エンコード オプションを制御できます。また、メッセージを作成するときに、[宛先]、[Cc]、または [Bcc] フィールドの特定の受信者の変換オプションをオーバーライドできます。 Exchange 組織の受信者は、これらのオプションを使用できません。

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

TNEF 変換オプション

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

  • リモート ドメイン設定
  • メール ユーザーおよびメール連絡先の設定
  • Outlook の設定(次を含む):
    • メッセージ形式
    • インターネット メッセージ形式
    • インターネット受信者のメッセージ形式

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

メッセージ エンコード オプションは、次のレベルで指定できます。

  • リモート ドメイン設定
  • メール ユーザーおよびメール連絡先の設定
  • 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 7 ビット このヘッダー フィールドでは、メッセージに関する次の情報を記述できます。
  • メッセージ本文に存在する US-ASCII 形式ではないテキストまたはバイナリ データの変換に使用したエンコーティングのアルゴリズム。
  • メッセージ本文の現在の条件を示す指標。

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

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

  • 引用符で囲まれた印刷可能: このエンコード アルゴリズムでは、印刷可能な US-ASCII 文字を使用してメッセージ本文データをエンコードします。 元のメッセージ テキストの大部分が US-ASCII テキストである場合は、Quoted-printable エンコーディングによってある程度判読できる小サイズの結果が得られます。 等号 (=) 文字を除くすべての印刷可能な US-ASCII テキスト形式の文字は、エンコーディングを行わなくても表すことができます。
  • Base64: このエンコード アルゴリズムは、主に RFC 1421 で定義されているプライバシー強化メール (PEM) 標準に基づいています。 Base64 エンコーディングでは、PEM で定義されている 64 文字のアルファベットのエンコーディング アルゴリズムと出力スペース文字を使用して、メッセージ本文のデータをエンコードします。 Base64 エンコード メッセージのサイズは通常、元のメッセージよりも 33 % 大きくなります。 Base64 エンコードは、メッセージのサイズがどの程度増えるかを予測できるため、バイナリ データおよび US-ASCII 形式ではないテキストに最適です。

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

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

  • 7 ビット: この値は、メッセージ本文データが既に RFC 2822 形式であることを示します。 具体的には、次の条件が満たされている必要があることを意味しています。
    • テキストのすべての行は 998 文字以下にする必要があります。
    • すべての文字が US-ASCII 1 ～ 127 の範囲の文字によるテキスト形式である必要があります。
    • CR および LF 文字は、テキスト行の末尾を表すために、常に組み合わせて使用されます。

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

    7 ビット本文を持つメッセージは、標準の DATA コマンドを使用して SMTP メッセージング サーバー間を移動できます。

  • 8 ビット: この値は、メッセージ本文データに US-ASCII 以外の文字が含まれていることを示します。 具体的には、次の条件が満たされている必要があることを意味しています。
    • テキストのすべての行は 998 文字以下にする必要があります。
    • メッセージ本文の 1 つ以上の文字の値が 127 を超えています。
    • CR および LF 文字は、テキスト行の末尾を表すために、常に組み合わせて使用されます。

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

    8 ビット本文を持つメッセージは、EXCHANGE 2000 Server 以降を実行しているサーバーなど、RFC 1652 で定義されている 8BITMIME SMTP 拡張機能をサポートする SMTP メッセージング サーバー間でのみ送信できます。 具体的には、次の条件が満たされている必要があることを意味しています。

    • サーバーの EHLO 応答では、 8BITMIME キーワードを宣言する必要があります。
    • この場合でも、メッセージは SMTP 標準の DATA コマンドを使用して転送されます。 ただし、BODY=8BITMIME パラメーターを MAIL FROM コマンドの最後に追加する必要があります。
  • バイナリ: この値は、メッセージ本文に US-ASCII 以外のテキスト データまたはバイナリ データが含まれていることを示します。 具体的には、次の条件が満たされていることを意味しています。
    • 任意の文字列が許可されます。
    • 行の長さに制限はありません。
    • バイナリ メッセージ要素には、エンコーディングは不要です。

    バイナリ本文を持つメッセージは、EXCHANGE 2000 Server 以降を実行しているサーバーなど、RFC 3030 で定義されている BINARYMIME SMTP 拡張機能をサポートする SMTP メッセージング サーバー間でのみ移動できます。 具体的には、次の条件が満たされている必要があることを意味しています。

    • サーバーの EHLO 応答では、 BINARYMIME キーワードを宣言する必要があります。
    • BINARYMIME SMTP 拡張は、必ず CHUNKING 拡張と共に使用する必要があります。 チャンクを 使用すると、大きなメッセージ本文を複数の小さなチャンクで送信できます。 チャンキングは、RFC 3030 でも定義されています。 サーバーの EHLO 応答で CHUNKING キーワードを宣言する必要もあります。
    • メッセージは、標準 DATA コマンドの代わりに BDAT コマンドを使用して転送されます。
    • メッセージにメッセージ本文が含まれている場合は、MAIL FROM コマンドの最後に BODY=BINARYMIME パラメーターを追加する必要があります。

7 ビット、8 ビット、バイナリの値は、同じマルチパート メッセージに一緒に存在しません。 値は相互に排他的です。 引用符で囲まれた印刷可能な値または Base64 値は、7 ビットまたは 8 ビットのマルチパート メッセージ本文に表示されますが、バイナリ メッセージ本文には表示されません。 マルチパート メッセージ本文に 7 ビットと 8 ビットのコンテンツで構成される異なる部分が含まれている場合、メッセージ全体は 8 ビットとして分類されます。 マルチパート メッセージ本文に 7 ビット、8 ビット、およびバイナリ コンテンツで構成される異なる部分が含まれている場合、メッセージ全体がバイナリとして分類されます。
Content-Disposition 添付ファイル このヘッダー フィールドは、RFC 2183 で定義されているとおりに、MIME が有効な電子メール クライアントに添付ファイルの表示方法に関する指示を与えます。 このフィールドの値は、Inline または Attachment です。 このフィールドの値が Inline である場合、添付ファイルはメッセージ本文に表示されます。 このフィールドの値が Attachment である場合、添付ファイルはメッセージ本文から分離された通常の添付ファイルとして表示されます。 値が Attachment である場合、Filename、Creation-date、Size などの他のパラメーターを使用できます。