Share via

再生ディレクトリの管理

  • [アーティクル]

 

適用先: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

トピックの最終更新日: 2007-02-22

既定では、ハブ トランスポート サーバーの役割またはエッジ トランスポート サーバーの役割がインストールされているすべての Microsoft Exchange Server 2007 コンピュータに再生ディレクトリが存在しています。正しい形式の電子メール メッセージ ファイルを再生ディレクトリにコピーすると、そのメッセージ ファイルが配信のために送信されます。再生ディレクトリは、外部ゲートウェイ サーバーからメッセージを受信し、管理者が Exchange 2007 サーバーのキューからエクスポートするメッセージを再送信します。

再生ディレクトリのすべての構成タスクに、Set-TransportServer コマンドレットを使用します。このコマンドレットを使用すると、再生ディレクトリに対して次のような構成変更を行うことができます。

  • 再生ディレクトリを有効または無効にします。
  • 再生ディレクトリの場所を指定します。
  • メッセージ ファイルの処理の最大速度を 1 分あたりのメッセージ数で指定します。

再生ディレクトリのメッセージ処理方法

適切な書式が設定され、再生ディレクトリにコピーされた .eml メッセージ ファイルは、次の手順で送信用に処理されます。

  1. 再生ディレクトリは 5 秒ごとに新しいメッセージ ファイルがあるかどうかをチェックします。このポーリング間隔は変更できません。メッセージ ファイルの処理速度は、Set-TransportServer コマンドレットの PickupDirectoryMaxMessagesPerMinute パラメータを使用して調整することができます。既定値は 1 分あたり 100 メッセージです。開けないファイルは再生ディレクトリに残り、次のポーリングで再試行されます。
  2. ファイル名が <ファイル名>.eml から <ファイル名>.tmp に変更されます。<ファイル名>.tmp ファイルが既に存在する場合は、<ファイル名><日時>.tmp に変更されます。ファイル名の変更に失敗した場合、イベント ログ エラーが生成され、再生処理は次のファイルに移ります。
  3. .tmp ファイルが電子メール メッセージに正しく変換されると, .tmp ファイルに対して "delete on close" コマンドが発行されます。.tmp ファイルは再生ディレクトリに残っているように見えますが、他のユーザーがファイルを開くことはできません。
  4. メッセージが配信用のキューに登録されたら、"close" コマンドが発行され, .tmp ファイルは再生ディレクトリから削除されます。削除に失敗した場合は、イベント ログにエラーが生成されます。再生ディレクトリに .tmp ファイルがある状態で Microsoft Exchange トランスポート サービスが再起動すると、すべての .tmp ファイルの名前は .eml ファイルに変更され、再処理されます。この場合は、メッセージ転送が重複する可能性があります。

電子メール メッセージ ファイルの詳細

標準的な SMTP 電子メール メッセージは、メッセージ エンベロープとメッセージのコンテンツで構成されます。メッセージ エンベロープには、メッセージの転送と配信に必要な情報が含まれます。メッセージのコンテンツには、総称して "メッセージ ヘッダー" と呼ばれるメッセージ ヘッダー フィールドとメッセージ本文があります。メッセージ エンベロープは RFC 2821 で定義され、メッセージ ヘッダーは RFC 2822 で定義されます。

送信者が電子メール メッセージを作成し、配信のために送信した段階でメッセージに含まれるのは、SMTP 標準に準拠するために必要な基本的な情報 (送信者、受信者、メッセージの作成日時、省略可能な件名、省略可能なメッセージ本文など) です。この情報は、メッセージ自体 (定義上はメッセージ ヘッダー) に含まれます。送信者のメッセージング サーバーは、メッセージ ヘッダーで見つかった送信者と受信者の情報を使用してメッセージのメッセージ エンベロープを生成し、配信のためにメッセージをインターネットに送信します。メッセージ エンベロープはメッセージ送信プロセスによって生成されるものであり、実際にはメッセージの一部ではないため、受信者がメッセージ エンベロープを目にすることはありません。メッセージの送信に関与する各サーバーによって、メッセージの配信におけるサーバーの役割に関連するメッセージ ヘッダー フィールドや、その他のアプリケーション固有のメッセージ ヘッダー フィールドがメッセージに挿入される場合もあります。受信者が電子メール クライアントを使用してメッセージを開くと、メッセージ ヘッダーの情報のうち、送信者、受信者、件名などの関連性の高い情報が、メッセージ本文と共に表示されます。

メッセージ エンベロープとメッセージ ヘッダーの関係は、大企業で従来の手紙を発送する場合にたとえるとわかりやすくなります。一番上に自分の会社の住所と受取人の住所を記した正式なビジネス レターを書いたとします。その手紙を、社内の郵便仕分け室の担当者に渡します。郵便仕分け室の担当者は、手紙の受取人の情報に基づいて封筒 (エンベロープ) を準備し、手紙を封筒に入れて、封筒を配達のためにメールボックスに入れます。その封筒は、封筒に書かれた住所に基づいて、受取人の会社へと郵便で配達されます。受取人の会社の郵便仕分け室の担当者は、封筒を受け取ると、封筒に書かれた宛名から受取人を特定し、封筒を空けて、手紙を受取人の個人用メールボックスに入れます。自分のメールボックスから手紙を取り出した受取人には、その手紙が差出人から自分宛てに届いた手紙であることが、手紙の一番上に書かれた宛名からわかります。

再生ディレクトリのメッセージ ファイルの要件

再生ディレクトリは、エクスポートされた Exchange メッセージの再送信と外部ゲートウェイ サーバーからのメッセージ受信に使用されます。これらのメッセージは、再生ディレクトリ用にあらかじめ書式設定されています。管理者や他のアプリケーションが再生ディレクトリを使用することにより、新しいメッセージ ファイルを作成して送信する必要はほとんどありません。新しいメッセージ ファイルを作成して送信するには、ピックアップ ディレクトリを使用します。

再生ディレクトリ メッセージは X-Header を最大限に活用します。X-Header は、メッセージ ヘッダーに含まれている、ユーザー定義の非公式なメッセージ ヘッダー フィールドです。X-Header は RFC 2822 で具体的に記述されているわけではありませんが、"X-" で始まる未定義のメッセージ ヘッダー フィールドの使用は、メッセージに非公式なメッセージ ヘッダー フィールドを追加する方法として受け入れられています。再生ディレクトリ内のメッセージ ファイルで使用される Exchange 2007 固有の X-Header によって、通常はメッセージ エンベロープ内に存在する配信情報を実際に設定できます。この機能は、再生ディレクトリを使用して、別の Exchange サーバーからエクスポートされたメッセージを処理するときに、元のメッセージ情報を保持するために必要になります。

再生ディレクトリにコピーされたメッセージ ファイルを正常に配信するには、次の要件を満たす必要があります。

  • メッセージ ファイルは、基本的な SMTP メッセージ形式に準拠するテキスト ファイルである必要があります。MIME (Multipurpose Internet Mail Extensions) メッセージ ヘッダー フィールドとコンテンツがサポートされます。
  • メッセージ ファイルのファイル名には, .eml 拡張子が付いている必要があります。
  • X-Header は、すべての通常のヘッダー フィールドの前に付いている必要があります。
  • ヘッダー フィールドとメッセージ本文の間に空白行が存在する必要があります。

次に示す X-Header は、再生ディレクトリ内にあるメッセージの必須のフィールドです。

  • X-Sender:   この X-Header は、標準の SMTP メッセージ内の From: メッセージ ヘッダー フィールド要件に替わります。 1 つの電子メール アドレスを含む 1 つの X-Sender: フィールドが存在する必要があります。From: メッセージ ヘッダー フィールドがある場合、再生ディレクトリはこれを無視します。ただし、受信者の電子メール クライアントには、メッセージの送信者として From: メッセージ ヘッダー フィールドの値が表示されます。次の例で示すように、他のパラメータは通常、X-Sender: フィールドに存在します。

    X-Sender: <bob@fabrikam.com> BODY=7bit RET=HDRS ENVID=12345ABCD auth=<someAuth>
    note注 :
    これらのパラメータは、通常は送信側サーバーによって生成されるメッセージ エンベロープ値です。エクスポートされたメッセージ ファイルを開くと、このようなパラメータを見かけるでしょう。
    RET= には、メッセージを配信できない場合、メッセージ全体を戻すか、ヘッダーのみを戻すかを指定します。RET= に指定できる値は、HDRS または FULL です。
    ENVID= は、メッセージ エンベロープの識別子です。BODY= には、メッセージのテキスト エンコーディングを指定します。AUTH= には、RFC 2554 に定義されている、メッセージング サーバーに対する認証機構を指定します。

  • X-Receiver:   この X-Header は、標準の SMTP メッセージ内の To: メッセージ ヘッダー フィールド要件に替わります。 1 つの電子メール アドレスを含む 1 つ以上の X-Receiver: フィールドが存在する必要があります。複数の受信者がいる場合は、複数の X-Receiver: フィールドを含めることができます。To: メッセージ ヘッダー フィールドがある場合、再生ディレクトリはこれを無視します。ただし、受信者の電子メール クライアントには、メッセージの受信者として To: メッセージ ヘッダー フィールドの値が表示されます。次の例で示すように、他の省略可能なパラメータが、X-Receiver: フィールドに存在することがあります。

    X-Receiver: <mary@contoso.com> NOTIFY=NEVER ORcpt=mary@contoso.com
    note注 :
    これらのパラメータは、通常は送信側サーバーによって生成されるメッセージ エンベロープ値です。エクスポートされたメッセージ ファイルを開くと、このようなパラメータを見かけるでしょう。これらのパラメータは、RFC 1891 に定義されている配信状態通知 (DSN) メッセージに関連しています。NOTIFY= に指定できる値は、NEVER、DELAY、または FAILURE です。ORcpt= は、メッセージの元の受信者を保存するために使用されます。

次に示す X-Header は、再生ディレクトリ内のメッセージ ファイル用のフィールドです。これらは省略可能です。

  • X-CreatedBy:   この X-Header が存在する場合、このヘッダーを空白にすることはできません。X-CreatedBy: フィールドが存在しない場合、このフィールドが Unspecified という値と共に追加されます。通常、このフィールドの値は MSExchange12 ですが、Notes などの送信コネクタで設定されている、SMTP 以外のアドレス スペースを含めることもできます。このメッセージ ヘッダー フィールドは、ヘッダー ファイアウォール機能で使用されます。
  • X-EndOfInjectedXHeaders:   存在するすべての X-Header のサイズをバイト数で表します。この X-Header は、通常のメッセージ ヘッダー フィールドが始まる直前の X-Header フィールドを示すマーカーとして使用されることがあります。
  • X-ExtendedMessageProps:   メッセージの拡張メッセージ プロパティです。
  • X-HeloDomain:   最初の SMTP プロトコル通信中に表示される HELO/EHLO ドメイン文字列です。
  • X-LegacyExch50:   Exchange 2003 サーバーが存在する場合、Exchange Server 2003 によって生成されたカスタム プロパティを保存するために使用されます。
  • X-Source:   この X-Header が指定されない場合、Replay の値が使用されます。この X-Header は、キュー ビューアの [メッセージの送信元の名前] 列で使用されます。この X-Header で使用できるその他の値として、Smtp Receive Connector と Smtp Send Connector があります。
  • X-SourceIPAddress:   送信側サーバーの IP アドレスです。IP アドレスが指定されない場合、このフィールドは 0.0.0.0 になります。

次は、再生ディレクトリで受け入れ可能な書式を使用するテキスト メッセージの例です。

X-Receiver: <mary@contoso.com> NOTIFY=NEVER ORcpt=mary@contoso.com
X-Sender: <bob@contoso.com> BODY=7bit ENVID=12345AB auth=<someAuth>
Subject: Optional message subject

This is the body of the message.

再生ディレクトリ メッセージ ファイルでは MIME コンテンツもサポートされます。MIME では、7 ビットの ASCII テキストでは表現できない言語、HTML、その他のマルチメディア コンテンツなど、広範なメッセージのコンテンツが定義されています。MIME の詳細な説明とその要件に関しては、ここでは扱いません。次は、再生ディレクトリで受け入れ可能な書式を使用する簡単な MIME メッセージの例です。

X-Receiver: <mary@contoso.com> NOTIFY=NEVER ORcpt=mary@contoso.com
X-Sender: <bob@contoso.com> BODY=7bit ENVID=12345ABCD auth=<someAuth>
To: mary@contoso.com
From: bob@contoso.com
Subject: Optional message subject
MIME-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

<HTML><BODY>
<TABLE>
<TR><TD>cell 1</TD><TD>cell 2</TD></TR>
<TR><TD>cell 3</TD><TD>cell 4</TD></TR>
</TABLE>

</BODY></HTML>

再生ディレクトリ内のメッセージ ファイルに加えられるメッセージ ヘッダーの変更

再生ディレクトリでは、メッセージ ファイルから Bcc: メッセージ ヘッダー フィールドが削除されます。

再生ディレクトリでは、メッセージ送信プロセスの中で、独自の Received: メッセージ ヘッダー フィールドがメッセージに追加されます。Received: メッセージ ヘッダー フィールドは次の形式で適用されます。

Received: from <ReceivingServerName> by Replay with <ExchangeServerVersion><DateTime>

再生ディレクトリでは、メッセージ ヘッダー内の次のメッセージ ヘッダー フィールドが変更されます。

  • Message-ID:   このメッセージ ヘッダー フィールドが欠落しているか空白である場合、再生ディレクトリでは <GUID>@<既定のドメイン> という形式で Message-ID: メッセージ ヘッダー フィールドが追加されます。
  • Date:   このメッセージ ヘッダー フィールドが欠落しているか形式に誤りがある場合、再生ディレクトリでは、再生ディレクトリによるメッセージの処理日時を使用して Date: メッセージ ヘッダー フィールドが追加されます。

再生ディレクトリ メッセージ処理の失敗

メッセージ ファイルから電子メール メッセージへの変換過程で問題が発生すると、再生ディレクトリでは、メッセージが配信不能 (不正メール) と見なされます。不正メール メッセージ ファイルには、送信者の欠落、受信者の欠落、書式設定の問題など、重大な問題があります。不正メールと判定されるメッセージ ファイルは再生ディレクトリに残され、ファイル名が <ファイル名>.eml から <ファイル名>.bad に変更されます。<ファイル名>.bad ファイルが既に存在する場合、ファイル名は <ファイル名><日時>.bad に変更されます。再生ディレクトリに不正メールが存在する場合、イベント ログ エラーが生成されますが、1 つの不正メール メッセージによってイベント ログ エラーが繰り返し生成されることはありません。

再生ディレクトリのセキュリティに関する問題

Exchange Server 2003 では、テキスト メッセージ ファイルの作成と送信に 1 つのピックアップ ディレクトリが使用されます。Exchange 2007 では、この機能がピックアップ ディレクトリと再生ディレクトリに分割されています。ピックアップ ディレクトリは、ユーザーやアプリケーションが手動でメッセージ ファイルを新規作成する際に使用されます。再生ディレクトリは、エクスポートされた Exchange 電子メール メッセージの再送信や、SMTP 以外のコネクタからのメッセージの受信に使用されます。このように任務を分けることで、一方のディレクトリに適切なセキュリティを他方のディレクトリの機能に影響を及ぼすことなく適用できます。

次の一覧は、ピックアップ ディレクトリと再生ディレクトリに共通するセキュリティ上の問題です。

  • スパム対策、ウイルス対策、送信者フィルタの操作、受信者フィルタの操作など、受信コネクタに構成されているセキュリティ チェックは、ピックアップ ディレクトリと再生ディレクトリから送信されるメッセージに対して、メッセージ送信時には実行されません。
  • 侵害されたピックアップ ディレクトリや再生ディレクトリが第三者中継として機能する可能性があります。これにより、別のサーバーを使って実際のメッセージの送信元を隠すことで、メッセージを再送信または "中継" することができます。

次の一覧は、再生ディレクトリに当てはまるセキュリティ上のさらなる問題です。

  • 再生ディレクトリで使用される X-Header を使用すると、メッセージ エンベロープを手動で作成することができます。X-Sender: および X-Receiver: フィールドの情報は、電子メール クライアントで表示される To: または From: メッセージ ヘッダー フィールドとはまったく異なる場合があります。このような送信者やドメインのなりすましは、多くの場合、スプーフィングと呼ばれます。スプーフィングされたメールは、メッセージの実際の送信者とは別の送信者から発信されたように見せるために送信者アドレスが変更された電子メール メッセージです。
  • X-CreatedBy: フィールドの値が MSExchange12 である場合、送信先は信頼できると見なされ、ヘッダー ファイアウォールは適用されません。ヘッダー ファイアウォールは、信頼できる Exchange 2007 サーバー間で転送されるメッセージ内の X-Header を保存したり、Exchange 組織外部の信頼できない送信先に転送されるメッセージから、情報漏洩の可能性がある X-Header を削除するための Exchange の手段です。これらの X-Header は、権限のある Exchange 2007 サーバー間の SCL (Spam Confidence Level)、メッセージの署名、暗号化などの Exchange 2007 情報を共有するために使用されることがあります。権限のない送信元にこの情報が漏れると、セキュリティ上のリスクを抱える可能性があります。

ピックアップ ディレクトリと再生ディレクトリの分離により、各ディレクトリに異なるレベルのセキュリティを適用できます。再生ディレクトリに関連するセキュリティ リスクが多いので、再生ディレクトリに適用するセキュリティを強化する必要があります。新しいメッセージを生成して送信する必要があるユーザーやアプリケーションには、ピックアップ ディレクトリへのアクセス許可が与えられますが、再生ディレクトリへのアクセス許可は不要です。

再生ディレクトリのアクセス許可

再生ディレクトリには、以下のアクセス許可が必要です。

  • 管理者 : フル コントロール
  • システム : フル コントロール
  • ネットワーク サービス : サブフォルダとファイルの読み取り、書き込み、および削除

既定では、Microsoft Exchange トランスポート サービスはネットワーク サービス ユーザー アカウントのセキュリティ資格情報を使用して、再生ディレクトリの場所とアクセス許可を管理します。ネットワーク サービス アカウントは, .eml ファイルを開いたり、名前を .tmp に変更して削除したり、メッセージが不正メールとして分類される場合は名前を .bad に変更したりできるように、再生ディレクトリに対するこれらのアクセス許可が必要です。

再生ディレクトリの場所は、Set-TransportServer コマンドレットの ReplayDirectoryPath パラメータを使用して移動することができます。再生ディレクトリの場所を変更できるかどうかは、変更先の再生ディレクトリでネットワーク サービス アカウントに与えられているアクセス許可と、変更先の再生ディレクトリが既に存在しているかどうかによります。変更先の再生ディレクトリが存在しておらず、ネットワーク サービス アカウントが変更先の場所でフォルダを作成してアクセス許可を適用するために必要なアクセス許可を持っている場合、再生ディレクトリが新規作成され、適切なアクセス許可が適用されます。新しい再生ディレクトリが既に存在している場合、既存フォルダのアクセス許可はチェックされません。Set-TransportServer コマンドレットで ReplayDirectoryPath パラメータを使って再生ディレクトリを移動する場合は常に、変更先のディレクトリが存在すること、およびそのディレクトリに適切なアクセス許可が適用されていることの確認をお勧めします。再生ディレクトリの変更に失敗した場合、Set-TransportServer コマンドレットで ReplayDirectoryPath パラメータを使用する前に、再生ディレクトリを新規作成して、適切なアクセス許可を適用することができます。

詳細情報

詳細については、以下のトピックを参照してください。

参照している情報が最新であることを確認したり、他の Exchange Server 2007 ドキュメントを見つけたりするには、Exchange Server TechCenter を参照してください。