次の方法で共有

ピックアップ ディレクトリと再生ディレクトリ

  • [アーティクル]

製品: Exchange Server 2013

既定では、ピックアップ ディレクトリおよび再生ディレクトリは各 Microsoft Exchange Server 2013 メールボックス サーバーまたはエッジ トランスポート サーバーに存在します。 正しい形式の電子メール メッセージ ファイルをピックアップ ディレクトリまたは再生ディレクトリにコピーすると、そのメッセージ ファイルが配信のために送信されます。 ピックアップ ディレクトリは、管理者がメール フローのテストに使用したり、独自のメッセージを作成して送信したりする必要があるアプリケーションが使用します。 再生ディレクトリは、外部ゲートウェイ サーバーからメッセージを受信し、管理者が Exchange サーバーのキューからエクスポートするメッセージを再送信するのにも使用できます。

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

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

送信者が電子メール メッセージを作成し、配信のために送信した段階でメッセージに含まれるのは、SMTP 標準に準拠するために必要な基本的な情報 (送信者、受信者、メッセージの作成日時、省略可能な件名、省略可能なメッセージ本文など) です。 この情報は、メッセージ自体 (定義上はメッセージ ヘッダー) に含まれます。

送信者のメッセージング サーバーは、メッセージ ヘッダーで見つかった送信者と受信者の情報を使用してメッセージのメッセージ エンベロープを生成し、受信者のメッセージング サーバーに配信するためにメッセージをインターネットに送信します。 メッセージ エンベロープはメッセージ送信プロセスによって生成されるものであり、実際にはメッセージの一部ではないため、受信者がメッセージ エンベロープを目にすることはありません。

メッセージの送信に関与する各サーバーによって、メッセージの配信におけるサーバーの役割に関連するメッセージ ヘッダー フィールドや、その他のアプリケーション固有のメッセージ ヘッダー フィールドがメッセージ ヘッダーに挿入される場合もあります。 受信者が電子メール クライアントを使用してメッセージを開くと、メッセージ ヘッダーの情報のうち、送信者、受信者、件名などの比較的関連性の高い情報が、メッセージ本文と共に表示されます。

ピックアップ ディレクトリおよび再生ディレクトリのメッセージ処理方法

Exchange 2013 では、ピックアップ ディレクトリの既定の場所は です %ExchangeInstallPath%TransportRoles\Pickup。 再生ディレクトリの既定の場所は です %ExchangeInstallPath%TransportRoles\Replay。 適切な書式が設定され、ピックアップ ディレクトリまたは再生ディレクトリにコピーされた .eml メッセージ ファイルは、次の手順で送信用に処理されます。

  1. ピックアップ ディレクトリおよび再生ディレクトリでは新しいメッセージ ファイルの有無が 5 秒ごとに確認されます。 このポーリング間隔は変更できません。 メッセージ ファイル処理の速度は、Set-TransportService コマンドレットの PickupDirectoryMaxMessagesPerMinute パラメーターを使用して調整できます。 このパラメーターは、ピックアップ ディレクトリと再生ディレクトリに影響します。 既定値は 1 分あたり 100 メッセージです。 開くことのできないファイルはピックアップ ディレクトリに残り、次のポーリング時に再評価されます。

  2. ピックアップ ディレクトリのメッセージ ファイルに適用される制限 (最大ヘッダー サイズ、受信者の最大数など) が確認されます。 既定では、最大ヘッダー サイズは 64 KB、受信者の最大数は 100 です。 Set-TransportService コマンドレットを使用して、これらの制限を変更できます。 これらの設定は、ピックアップ ディレクトリだけに影響します。

  3. ファイルの名前は filename.eml> から<filename.tmp> に<変更されます。 <filename.tmp> ファイルが既に存在する場合、ファイル名は filename><datetime.tmp> として名前が<変更されます。 ファイル名の変更に失敗した場合はイベント ログにエラーが生成されて、ピックアップ プロセスは次のファイルに進みます。

  4. .tmp ファイルが電子メール メッセージに正しく変換されると, .tmp ファイルに対して delete on close コマンドが発行されます。 .tmp ファイルはピックアップ ディレクトリに残っているように見えますが、そのファイルを開くことはできません。

  5. メッセージが配信用のキューに登録されたら、 close コマンドが発行され, .tmp ファイルはピックアップ ディレクトリから削除されます。 削除に失敗した場合は、イベント ログにエラーが生成されます。 ピックアップ ディレクトリに .tmp ファイルが残っている状態で Microsoft Exchange トランスポート サービスが再起動されると、すべての .tmp ファイルの名前が .eml ファイルに変更されて再処理されます。 この場合は、メッセージ転送が重複する可能性があります。

ピックアップ ディレクトリのメッセージ ファイルの要件

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

  • メッセージ ファイルは、基本的な SMTP メッセージ形式に準拠するテキスト ファイルである必要があります。 MIME メッセージ ヘッダー フィールドとコンテンツがサポートされます。

  • メッセージ ファイルのファイル名には, .eml 拡張子が付いている必要があります。

  • メッセージ ヘッダーのまたはFromメッセージ ヘッダー フィールドにSender、少なくとも 1 つの電子メール アドレスが存在する必要があります。 フィールドと From フィールドの両方Senderに 1 つの電子メール アドレスが存在する場合、フィールドのFrom電子メール アドレスがメッセージ エンベロープ内のメッセージの発信者として使用されます。

  • フィールドに存在できる電子メール アドレスは Sender 1 つだけです。 複数の電子メール アドレスは許可されません。 フィールドに Sender 電子メール アドレスが 1 つだけ存在する場合、 From フィールドは省略可能です。

  • フィールドには複数のメール アドレスを From 使用できますが、フィールドには 1 つのメール アドレスも存在 Sender する必要があります。 フィールド内の Sender アドレスは、メッセージ エンベロープ内のメッセージの発信元として使用されます。

  • 、または Bcc フィールドには、少なくとも 1 つの電子メール アドレスがToCc存在する必要があります。

  • メッセージ ヘッダーとメッセージ本文の間に空白行が存在する必要があります。

この例では、ピックアップ ディレクトリで受け入れ可能な形式を使用しているテキスト メッセージを示します。

To: mary@contoso.com
From: bob@fabrikam.com
Subject: Message subject

This is the body of the message.

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

To: mary@contoso.com
From: bob@fabrikam.com
Subject: 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>

ピックアップ ディレクトリのメッセージ ヘッダーの変更

ピックアップ ディレクトリでは、次のメッセージ ヘッダー フィールドがメッセージ ヘッダーからすべて削除されます。

  • Received

  • Resent-*

  • Bcc

    注:

    メッセージ ヘッダーの省略可能な Bcc メッセージ ヘッダー フィールドに見つかった電子メール アドレスは、正しく処理されます。 受信者が非表示の Bcc メッセージ エンベロープ受信者に昇格されると、ID を保護するためにメッセージ ヘッダーから削除されます。 メッセージに受信者のみが Bcc 含まれている場合は、 未公開の受信者 の値がメッセージ ヘッダーの To フィールドに追加されます。

ピックアップ ディレクトリは、メッセージ送信プロセスの一部として、独自 Received のヘッダー フィールドをメッセージに追加します。 Receivedヘッダー フィールドは次の形式で適用されます。

Received: from localhost by Pickup with Microsoft SMTP Server id <ExchangeServerVersion><datetime>

ピックアップ ディレクトリでは、次のメッセージ ヘッダー フィールドが存在しない場合または正しくない場合に、次のような変更が加えられます。

  • メッセージ ID: フィールドが見つからないか空の場合Message-Id、ピックアップ ディレクトリは GUID>defaultdomain 形式<を使用してMessage-Id フィールドを追加します>。<@

  • 日付: フィールドが Date 見つからないか、形式が正しくない場合、ピックアップ ディレクトリは、ピックアップ ディレクトリによるメッセージ処理の日時を追加します。

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

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

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

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

  • メッセージ ファイルは、基本的な SMTP メッセージ形式に準拠するテキスト ファイルである必要があります。 MIME メッセージ ヘッダー フィールドとコンテンツがサポートされます。

  • メッセージ ファイルのファイル名には, .eml 拡張子が付いている必要があります。

  • X-Header は、すべての通常のヘッダー フィールドの前に付いている必要があります。

  • ヘッダー フィールドとメッセージ本文の間に空白行が存在する必要があります。

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

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

    X-Sender: <bob@fabrikam.com> BODY=7bit RET=HDRS ENVID=12345ABCD auth=<someAuth>

    注:

    これらのパラメーターは、通常は送信側サーバーによって生成されるメッセージ エンベロープ値です。 エクスポートされたメッセージ ファイルを開くと、このようなパラメーターを見かけることがあります。

    RET には、メッセージを配信できない場合、送信者にメッセージ全体を戻すか、ヘッダーのみを戻すかを指定します。 RETは、 または FULLのHDRS値を持つことができます。 ENVID は、メッセージ エンベロープの識別子です。 BODY には、メッセージのテキスト エンコーディングを指定します。 auth には、RFC 2554 に定義されている認証機構をメッセージング サーバーに対して指定します。

  • X-Receiver: この X ヘッダーは、一般的な SMTP メッセージの To メッセージ ヘッダー フィールド要件に置き換えられます。 1 つの X-Receiver 電子メール アドレスを含む少なくとも 1 つのフィールドが存在する必要があります。 複数の X-Receiver 受信者に対して複数のフィールドを使用できます。 再生ディレクトリは、メッセージ ヘッダー フィールドが存在する場合は無視 To しますが、受信者の電子メール クライアントではメッセージ ヘッダー フィールドの To 値がメッセージの受信者として表示されます。 次の例に示すように、フィールドには X-Receiver 他の省略可能なパラメーターが存在する場合があります。

    X-Receiver: <mary@contoso.com> NOTIFY=NEVER ORcpt=mary@contoso.com

    注:

    これらのパラメーターは、通常は送信側サーバーによって生成されるメッセージ エンベロープ値です。 エクスポートされたメッセージ ファイルを開くと、このようなパラメーターを見かけることがあります。 これらのパラメーターは、RFC 1891 に記述されている配信状態通知 (DSN) メッセージに関連するものです。

    NOTIFYには、、DELAY、または FAILUREのNEVER値を指定できます。 ORcpt は、メッセージの元の受信者を保持します。

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

  • X-CreatedBy: ヘッダー ファイアウォール機能に使用されます。 この X-Header が存在する場合、このフィールドを空白にすることはできません。 フィールドが X-CreatedBy 存在しない場合は、 値が Unspecified で追加されます。 通常、このフィールドの値は MSExchange15 ですが、 Notes など、送信コネクタで設定されている、SMTP 以外の種類のアドレス スペースを含めることもできます。

  • X-EndOfInjectedXHeaders: 存在するすべての X ヘッダーのサイズ (バイト単位)。 この X-Header は、通常のメッセージ ヘッダー フィールドが始まる直前の X-Header フィールドを示すマーカーとして使用されることがあります。

  • X-ExtendedMessageProps: メッセージの拡張メッセージ プロパティ。

  • X-HeloDomain: 最初の SMTP プロトコルの会話中に提示される HELO/EHLO ドメイン文字列。

  • X-Source: MessageSourceName 列のキュー ビューアーによって使用されます。 この X-Header の値が指定されない場合、 Replay という値が使用されます。 X-Header のその他の可能な値は、 Smtp Receive Connector および Smtp Send Connector です。

  • X-SourceIPAddress: 送信サーバーの IP アドレス。 このフィールドは、 0.0.0.0 IP アドレスが指定されていない場合です。

この例では、再生ディレクトリで受け入れ可能な形式を使用しているテキスト メッセージを示します。

X-Receiver: <mary@contoso.com> NOTIFY=NEVER ORcpt=mary@contoso.com

X-Sender: <bob@fabrikam.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@fabrikam.com> BODY=7bit ENVID=12345ABCD auth=<someAuth>
To: mary@contoso.com
From: bob@fabrikam.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>

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

  • メッセージ ID: このメッセージ ヘッダー フィールドが見つからないか空の場合、再生ディレクトリは GUID>defaultdomain 形式<を使用してメッセージ ID メッセージ ヘッダー フィールドを追加します>。<@

  • 日付: このメッセージ ヘッダー フィールドが見つからないか形式が正しくない場合、再生ディレクトリは、再生ディレクトリによるメッセージ処理の日時を使用して Date メッセージ ヘッダー フィールドを追加します。

ピックアップディレクトリおよび再生ディレクトリのメッセージ処理の失敗

ピックアップ ディレクトリまたは再生ディレクトリにコピーされたメッセージ ファイルを配信のためにキューに入れる処理が正しく行われない場合があります。 発生する可能性があるメッセージ送信エラーには、次のカテゴリがあります。

  • 配信エラー: 正しく書式設定されたメッセージ ファイルと、配信のために正常に送信できない有効な送信者が、配信不能レポート (NDR) を生成します。 内容の形式が正しくない場合や、ピックアップ ディレクトリ メッセージ制限に違反している場合も、NDRとなる場合があります。 メッセージ処理の間に NDR が生成されると、元のメッセージ ファイルが NDR メッセージに添付され、ピックアップ ディレクトリまたは再生ディレクトリからそのメッセージ ファイルが削除されます。

    注:

    トランスポート パイプラインに送信された正しい形式のメッセージが、その後の配信エラーによって、NDR と共に送信者に返される場合もあります。 この種のエラーは、メッセージング サーバーの障害やメッセージの配信パスでのルーティング エラーなど、ピックアップ ディレクトリまたは再生ディレクトリとは無関係の送信の問題によって発生します。

  • Badmail: badmail として分類されたメッセージには重大な問題があり、ピックアップディレクトリまたは再生ディレクトリが配信のためにメッセージを送信するのを妨げます。 また、メッセージの形式は正しいが受信者が有効ではなく、送信者も有効ではないために NDR メッセージを送信できない場合も、不正メールになります。

    不正と判断されたメッセージ ファイルは、ピックアップディレクトリまたは再生ディレクトリに残され、filename.eml から <filename.bad>>に<名前が変更されます。 <filename.bad> ファイルが既に存在する場合、ファイルの名前は filename><datetime.bad> に<変更されます。 ピックアップまたは再生ディレクトリに badmail が存在する場合は、イベント ログ エラーが生成されますが、同じ不正メッセージではイベント ログ エラーが繰り返し生成されません。

    注:

    メッセージ ファイルは常に、別の場所で作成と保存を行ってから、配信のためにピックアップ ディレクトリにコピーするようにしてください。 ピックアップ ディレクトリでは、5 秒ごとに新しいメッセージのポーリングが行われます。 このため、ピックアップ ディレクトリ自体でメッセージ ファイルの作成と保存を行うと、メッセージの作成が完了する前にメッセージ ファイルがピックアップ ディレクトリによって処理されてしまう可能性があります。

ピックアップ ディレクトリおよび再生ディレクトリに関するセキュリティ上の考慮事項

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

  • 受信コネクタで構成されているセキュリティ チェック (スパム対策、マルウェア対策、送信者フィルター、受信者フィルターの動作など) は、ピックアップ ディレクトリや再生ディレクトリを通じて送信されるメッセージに対しては実行されません。

  • 侵害されたピックアップ ディレクトリや再生ディレクトリが第三者中継として機能する可能性があります。 これにより、別のサーバーを使って実際のメッセージの送信元を隠すことで、メッセージを再送信または 中継 することができます。

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

  • 再生ディレクトリで使用される X-Header を使用すると、メッセージ エンベロープを手動で作成することができます。 および フィールドのX-Sender情報は、電子メール クライアントによって表示されるまたはFromメッセージ ヘッダー フィールドとは完全に異なるTo場合X-Receiverがあります。 このような送信者やドメインのなりすましは、多くの場合、スプーフィングと呼ばれます。 なりすましメールは、メッセージの実際の送信者とは別の送信者から発信されたように見せるために送信者アドレスが変更された電子メール メッセージです。

  • フィールドの X-CreatedBy 値が MSExchange15 の場合、宛先は信頼できると見なされ、ヘッダー ファイアウォールは適用されません。 Header firewall は、信頼できる Exchange サーバー間で転送されるメッセージ内の X-Header を保存したり、Exchange 組織外部の信頼できない送信先に転送されるメッセージから、情報漏洩の可能性がある X-Header を削除したりするための Exchange の手段です。 これらの X-Header は、権限のある Exchange サーバー間の SCL (Spam Confidence Level)、メッセージの署名、暗号化などの Exchange 情報を共有するために使用されることがあります。 権限のない送信元にこの情報が漏れると、セキュリティ上のリスクを抱える可能性があります。 ヘッダー ファイアウォールの詳細については、 "ヘッダー ファイアウォールについて"を参照してください。

再生ディレクトリに関連するセキュリティ リスクが多いので、再生ディレクトリに適用するセキュリティを強化する必要があります。 メッセージの作成や送信を行う必要があるユーザーやアプリケーションに対しては、ピックアップ ディレクトリへのアクセスのみを許可し、再生ディレクトリへのアクセスは許可しないようにしてください。

すべてのメールボックス サーバーとエッジ トランスポート サーバーでは、既定で、ピックアップ ディレクトリと再生ディレクトリの両方が有効になっています。 組織内の特定のメールボックス サーバーまたはエッジ トランスポート サーバーでピックアップ ディレクトリまたは再生ディレクトリが必要ない場合は、ピックアップ ディレクトリ パスまたは再生ディレクトリ パスを 値 $nullに設定することで、そのサーバーのピックアップ ディレクトリまたは再生ディレクトリを無効にすることができます。 詳細については、「 ピックアップ ディレクトリと再生ディレクトリの構成」を参照してください。

ピックアップ ディレクトリおよび再生ディレクトリに対するアクセス許可

ピックアップ ディレクトリおよび再生ディレクトリには次のアクセス許可が必要です。

  • 管理者: フル コントロール

  • システム :フル コントロール

  • Network Service: サブフォルダーとファイルの読み取り、書き込み、および削除

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

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