Share via

Exchange Serverでのコンテンツ変換

  • [アーティクル]

コンテンツ変換は、各受信者に合わせてメッセージの書式を正しく設定するプロセスです。 メッセージに対してコンテンツ変換を実行するかどうかの判断は、処理中のメッセージの送信先および書式に基づきます。 Exchange 2016 および Exchange 2019 で発生するコンテンツ変換の種類は、Exchange 2013 から変更されません。

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

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

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

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

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

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

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

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

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

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

    • 元の書式のメッセージ (例: フォント、テキスト サイズ、テキストの色)
    • OLE オブジェクト (例: 埋め込まれた画像や埋め込まれた Office 文書)
    • 特別な Outlook 機能 (例: カスタム フォーム、投票ボタン、会議出席依頼)
    • 元のメッセージ内にあった通常のメッセージの添付ファイル。

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

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

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

    • メッセージのプレーン テキスト バージョンが表示され、メッセージには Winmail.dat、Win.dat、またはその他の一般名 (Att nnnnn.dat や Att nnnnn.eml など) が含まれています。 nnnnn プレースホルダーは乱数を表します。
    • テキスト形式のメッセージが表示されます。 TNEF 添付ファイルは、無視されるか削除されます。 その結果、テキスト形式のメッセージになります。
    • TNEF を認識するメッセージング サーバーは、TNEF 添付ファイルを受信メッセージから削除するように構成することができます。 その結果、テキスト形式のメッセージになります。 さらに、一部の電子メール クライアントは、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 拡張をサポートして通知するメッセージング サーバー間のみで転送することができます。 メッセージは常に、標準 DATA コマンドの代わりに BDAT コマンドを使用して、メッセージング サーバー間で転送されます。

    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 という名前の付いたリモート ドメインが事前に定義されており、すべてのリモート アドレス スペース (*) に適用されます。 リモート ドメインの詳細については、「Remote Domains」を参照してください。

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

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

    • メッセージ形式: すべてのメッセージの既定のメッセージ形式を設定できます。 特定のメッセージを作成する際に既定のメッセージ形式を上書きできます。
    • インターネット メッセージ形式: TNEF メッセージをリモート受信者に送信するかどうか、または最初に互換性のある形式に変換するかどうかを制御できます。 また、リモートの受信者に送信するメッセージに対して、各種メッセージ エンコーディング オプションを指定できます。 これらの設定は、Exchange 組織の受信者に送信するメッセージには適用されません。
    • インターネット受信者メッセージの形式 (Outlook 2010 以前): TNEF メッセージを連絡先フォルダー内の特定の連絡先に送信するかどうかを制御できます。 Exchange 組織の受信者は、これらのオプションを使用できません。
    • インターネット受信者メッセージ エンコード オプション (Outlook 2010 以前): 連絡先フォルダー内の特定の連絡先の MIME またはプレーン テキスト エンコード オプションを制御できます。 Exchange 組織の受信者は、これらのオプションを使用できません。
    • 国際オプション: メッセージで使用される文字セットを制御できます。

    これらの設定の詳細については、Exchange Serverの TNEF 変換オプションとメッセージ エンコード オプションに関するページを参照してください。

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

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

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

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

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

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

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

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

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

MIME-Version ヘッダー フィールド

既定値: 1.0

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

Content-Type ヘッダー フィールド

既定値: text/plain

このヘッダー フィールドは、RFC 2046 の記述に基づいてメッセージ コンテンツのメディアの種類を定義します。 メディアの種類は、次で構成されます。

  • 型:

    • で x- 始まる型は標準ではありません。 IANA (Internet Assigned Numbers Authority) が、登録されているメディアの種類の一覧を管理しています。 詳細については、 MIME メディアの種類に関するページを参照してください (このサイトは英語の場合があります)。

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

  • サブタイプ: で始まる vnd. サブタイプはベンダー固有です。

  • 1 つ以上の省略可能なパラメーター: たとえば、 charset= MIME 文字エンコードを定義するパラメーター。

Content-Transfer-Encoding ヘッダー フィールド

既定値: 7bit

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

値 7bit、 8bit、および Binary は、同じマルチパート メッセージ内に一緒に存在することはありません (値は相互に排他的です)。 または Base64 の値はQuoted-printable、7 ビットまたは 8 ビットのマルチパート メッセージ本文に表示されますが、バイナリ メッセージ本文には表示されません。 マルチパート メッセージ本文に 7 ビットおよび 8 ビットのコンテンツで構成される複数の部分が含まれている場合、メッセージ全体は 8 ビットに分類されます。 マルチパート メッセージ本文に 7 ビット、8 ビット、バイナリ コンテンツで構成される複数の部分が含まれている場合、メッセージ全体はバイナリとして分類されます。

Content-Disposition ヘッダー フィールド

既定値: Attachment

このヘッダー フィールドは、RFC 2183 で定義されているとおりに、MIME が有効な電子メール クライアントに添付ファイルの表示方法に関する指示を与えます。 有効な値は次のとおりです。

  • Inline: 添付ファイルがメッセージ本文に表示されます。

  • Attachment: 添付ファイルは、メッセージ本文とは別の通常の添付ファイルとして表示されます。 その他のパラメーターも、この値 (、、FilenameCreation-date、 など) と共に使用されますSize。