Exchange Server 2003 のトランスポートおよびメッセージの流れに関する機能
Microsoft® Exchange Server 2003 では、トランスポートとメッセージの流れを強化するための新しい機能がいくつか追加されています。ここでは、以下について説明します。
- リンク状態の向上
ここでは、リンク状態の向上によって Exchange 組織全体にレプリケートされるリンク状態情報の量がどのように低減され、パフォーマンスへの悪影響がどのように低減されるかを説明します。
- クロス フォレスト認証の構成
Exchange 2003 は電子メール アドレスのスプーフィングや偽造を防止するため、特定の構成手順を実行してクロス フォレスト認証を有効にする必要があります。ここでは、クロス フォレスト認証を有効にする方法について説明します。
- インターネット メール ウィザード
Exchange 2003 には、組織内でのインターネット メール配信の構成を案内するインターネット メール ウィザードの新しいバージョンが用意されています。ここでは、ウィザードを使用してインターネット メール配信をセットアップする方法について説明します。
- 配信状態通知 (DSN) の診断ログ出力およびコード
Exchange 2003 には、配信状態通知 (DSN) の診断ログ出力が用意され、新しい DSN コードも実装されています。ここでは、DSN の診断ログ出力を構成する方法と、Exchange 2003 で使用できる新しい DSN コードについて説明します。
- X.400 (MTA) および SMTP キュー ディレクトリの移動のサポート
Exchange 2003 では、Exchange システム マネージャを使用して、SMTP および X.400 キュー データが格納される場所を変更できます。ここでは、Exchange システム マネージャを使用して、キュー ディレクトリを移動する方法について説明します。
- 接続フィルタ
Exchange 2003 は、ブロック リストに基づいた接続フィルタをサポートします。ここでは、接続フィルタのしくみと、Exchange サーバーで接続フィルタをセットアップする方法について説明します。
- 受信者のフィルタ
Exchange 2003 では受信者のフィルタもサポートされるため、Microsoft Active Directory® ディレクトリ サービス内に存在しないユーザー宛ての電子メール メッセージや、適切に定義された受信者宛ての不要な商用メールと思われる電子メール メッセージにフィルタを適用できます。
- SP2 の新機能 : 送信者 ID フィルタ
Exchange Server 2003 SP2 では、送信者 ID フィルタ機能を使用できます。送信者 ID は、迷惑な商用電子メール (UCE) およびフィッシングからコンピュータを保護するための電子メール業界標準です。特に、送信者 ID はドメインのスプーフィングを防止するために役立ちます。
- SP2 の新機能 : インテリジェント メッセージ フィルタ
Exchange Server 2003 SP2 では、インテリジェント メッセージ フィルタが Exchange Server 2003 SP2 のインストール時にインストールされるようになりました。
- 有効なフィルタの適用方法
ここでは、SMTP セッション中にフィルタと制限がどのように適用されるかについて説明します。
- SMTP 仮想サーバーへの発信を制限する機能の強化
ここでは、Exchange 2003 のセキュリティ グループに基づいて発信を制限する方法について説明します。
- SMTP 仮想サーバーでの中継を制限する機能の強化
ここでは、Exchange 2003 のセキュリティ グループに基づいて中継を制限する方法について説明します。
また、Exchange 2003 では、トランスポートとメールの流れを拡張するために、次のような機能も提供されています。
- クエリ ベース配布グループという名前の新しい種類の配布グループにより、LDAP クエリを使用して、配布グループのメンバシップを動的に構築できます。詳細については、「Exchange Server 2003 の管理機能」の「クエリ ベース配布グループ」および「メッセージ追跡機能の強化」を参照してください。
- 配布グループにメールを送信できるユーザーを制限できるようになりました。詳細については、「Exchange Server 2003 の管理機能」の「ユーザーおよび配布グループへの発信を制限する機能の強化 (配布グループの制限)」を参照してください。
- 分類 (ユーザーが検索され、配布グループが各受信者に展開される段階) 後、およびルーティング処理中に、メッセージを追跡できるようになりました。Exchange システム マネージャを使用して、メッセージ追跡ログを移動することもできます。詳細については、「Exchange Server 2003 の管理機能」の「メッセージ追跡機能の強化」を参照してください。
- キュー ビューアが強化されました。公開されるキューの数が増え、メールの流れに関連する問題をより簡単に診断できるようになりました。詳細については、「Exchange Server 2003 の管理機能」の「キュー ビューアの機能拡張」を参照してください。
- メールボックス ストアで使用できるアーカイブ機能により、BCC 行の受信者を含むすべての受信者をアーカイブできます。詳細については、「Exchange Server 2003 の管理機能」の「アーカイブされるメッセージに BCC 受信者を含める」を参照してください。
リンク状態の向上
Exchange はリンク状態ルーティングを使用して、サーバー間でメッセージを送信するための最適な方法を、メッセージ接続とコストの現在の状況に基づいて判断します。メッセージの代替パスが存在しない場合、または不安定な接続 (断続的に使用可能になったり使用不可能になったりする接続) が存在する場合について、Exchange 2003 ではリンク状態情報の通信方法が向上しています。具体的には、Exchange 2003 は、コネクタ状態が不安定かどうか、または代替パスが存在しないかどうかを判断することによって、リンク状態トラフィックを削減します。これらの条件のいずれかが存在する場合、Exchange はリンク状態情報を抑制します。
リンク状態の可用性の向上
Exchange 2003 では、リンクの代替パスが存在しない場合でも、リンク状態は常に有効 (サービス中) としてマークされます。代替パスが存在しなくても、使用不可能なリンク状態には変更されなくなりました。代わりに、Exchange はメールを配信用のキューに入れ、ルートが使用可能になったときに送信します。この変更によってリンク状態情報の送信が低減され、パフォーマンスが向上します。
不安定な接続に対するリンク状態の向上
リンク状態ルーティングに対するもう 1 つの大幅な機能強化は、Exchange 2003 が不安定な接続を処理する方法についての変更です。Exchange 2003 がリンク状態キューを確認し、コネクタに対して指定した間隔内で競合する状態変化が繰り返し発生する場合、コネクタは不安定な接続と見なされ、リンク状態は有効 (サービス中) のままとなります。リンク状態を頻繁に変更するよりも、不安定なコネクタを有効なままにしておくことをお勧めします。これにより、サーバー間でレプリケートされるリンク状態のトラフィック量が低減されます。
クロス フォレスト SMTP メール コラボレーションの構成
スプーフィング (なりすまし) を防ぐため、Exchange 2003 では、送信者の名前を GAL に登録された表示名に解決する場合、その送信者は認証されている必要があります。2 つのフォレストに広がる組織において、あるユーザーが他方のフォレストにメールを送信する場合、このユーザーは認証されません。このため、ユーザーの電子メール アドレスが GAL に登録された表示名に解決されることはありません。さらに、ユーザーが送信先フォレストの連絡先である場合でも、そのユーザーの名前は GAL 内の表示名に解決されません。
Exchange 2003 でクロス フォレスト メール コラボレーションを有効にするには、組織の外部の連絡先を Active Directory 内の表示名に解決するための追加の構成手順が必要となります。これらの連絡先の解決を有効にするためのオプションは 2 つあります。
- オプション 1 (推奨) 認証を使用して、フォレスト間でメールを送信するユーザーが認証されたユーザーであり、ユーザーの名前がグローバル アドレス一覧内の表示名に解決されるようにします。
- オプション 2 クロス フォレスト コラボレーションに使用される SMTP 仮想サーバーへのアクセスを制限し、匿名の電子メールを解決するように Exchange を構成します。この構成はサポートされていますが、お勧めできません。既定では、この構成では、フォレスト間でメールが送信されるときに、メッセージの拡張プロパティである Exch50 メッセージ プロパティが保持されません。
クロス フォレスト メール コラボレーションを構成する利点を理解するために、以下の匿名メール発信およびクロス フォレスト認証メールの発信シナリオについて考えます。
シナリオ : 匿名のメール発信
発信が匿名の場合、電子メール アドレスは解決されません。したがって、匿名ユーザーが内部ユーザーの ID をスプーフィング (なりすまし) してメールを送信すると、リターン アドレスはグローバル アドレス一覧内の表示名に解決されません。
例 :
Kim Akers は、Northwind Traders 社の正当な内部ユーザーです。グローバル アドレス一覧内の彼女の表示名は Kim Akers で、電子メール アドレスは kim@northwindtraders.com です。
メールを送信する場合、Kim は 認証を受ける必要があります。彼女は認証されるため、Kim のメールの受信者は、送信者が Kim Akers であることを確認できます。さらに、Kim Akers のプロパティは、彼女のグローバル アドレス一覧のエントリとして表示されます。ここで、Ted Bremer が From 行に kim@northwindtraders.com を使用し、そのメールを Northwind Traders 社の Exchange 2003 サーバーに送信して Kim のアドレスを偽造しようとした場合、Ted は認証されていないため、電子メール アドレスは Kim の表示名に解決されません。したがって、この電子メール メッセージが Microsoft Office Outlook® で表示されると、送信者アドレスは kim@northwindtraders.com と表示されます。Kim からの認証されたメールの場合と異なり、Kim Akers に解決されません。
シナリオ 2 : クロス フォレスト メール配信
Adatum フォレストと Fabrikam フォレストの 2 つのフォレストにわたる企業について考えます。これらのフォレストは、それぞれ adatum.com、fabrikam.com というドメインを含む単一ドメイン フォレストです。クロス フォレスト メール コラボレーションを可能にするために、Adatum フォレストのすべてのユーザーは、Fabrikam フォレストの Active Directory で連絡先として表されます。同様に、Fabrikam フォレストのすべてのユーザーは、Adatum フォレストの Active Directory で連絡先として表されます。
Adatum フォレストのユーザーが Fabrikam フォレストにメールを送信し、メールが匿名接続を介して発信された場合、その送信者が Active Directory と Outlook のグローバル アドレス一覧に連絡先として存在しても、送信者のアドレスは解決されません。これは、Adatum フォレストのユーザーが、Fabrikam フォレストにおいて認証されたユーザーではないためです。
例 :
Kim Akers は、Adatum フォレストのメール ユーザーです。彼女の電子メール アドレスは kim@adatum.com で、Outlook のグローバル アドレス一覧の表示名は Kim Akers です。Adam Barr は Fabrikam フォレストのユーザーです。彼の電子メール アドレスは abarr@fabrikam.com で、Outlook のグローバル アドレス一覧の表示名は Adam Barr です。Adam は Adatum フォレストで Active Directory 連絡先として表されているため、Kim は Adam の電子メール アドレスを表示して、Outlook のグローバル アドレス一覧で Adam Barr という表示名に解決できます。Adam が Kim からメールを受信したとき、Kim のアドレスは解決されません。グローバル アドレス一覧内に存在する Kim の表示名ではなく、Adam には彼女の未解決の電子メール アドレス kim@adatum.com が表示されます。Kim はメールを匿名ユーザーとして送信したため、彼女の電子メール アドレスは解決されませんでした。Kim はメールの送信時に認証されますが、2 つのフォレスト間の接続は認証されません。
一方のフォレストの送信者が他方のフォレストの受信者にメールを送信できるようにし、これらの電子メール アドレスがグローバル アドレス一覧内の表示名に解決されるようにするには、クロス フォレスト メール コラボレーションを有効にする必要があります。ここからは、2 つのフォレスト間でメール コラボレーションを構成する際に使用できる、2 つのオプションについて説明します。
Cross-Forest 認証の有効化
クロス フォレスト SMTP 認証を有効にするには、他のフォレストから認証されたアカウントを使用する各フォレストで、コネクタを作成する必要があります。これにより、認証されたユーザーによって 2 つのフォレスト間で送信されるメールが、グローバル アドレス一覧内の適切な表示名に解決されます。ここでは、クロス フォレスト認証を有効にする方法について説明します。
Adatum フォレストと Fabrikam フォレストの例 (前の「クロス フォレスト メール配信」のシナリオを参照) を使用し、次の手順を実行してクロス フォレスト認証をセットアップします。
- Fabrikam フォレストに、送信者アクセス許可を持つアカウントを作成します。Adatum フォレストのすべてのユーザーに対して、1 つの連絡先が Fabrikam フォレストにもあります。したがって、このアカウントにより、Adatum のユーザーは認証されたメールを送信できます。Adatum からの受信メールを許可するすべての Exchange サーバーで、これらのアクセス許可を構成します。
- Adatum フォレスト内の Exchange サーバーで、送信メールを送信する際にこのアカウントを使用した認証を要求するコネクタを作成します。
同様に、Fabrikam フォレストから Adatum フォレストへのクロス フォレスト認証をセットアップするには、これらの手順を繰り返して、Adatum にアカウントを作成し、Fabrikam にコネクタを作成します。詳細については、Exchange Server 2003 展開ガイドについてのページの、フォレスト間の SMTP 認証を有効にする方法に関する記述を参照してください (このサイトは英語の場合があります)。
匿名の電子メールの解決によるクロス フォレスト コラボレーションの有効化
組織の外部の連絡先を Active Directory 内の表示名に解決するように Exchange を構成するには、匿名の電子メールを解決するように Exchange を構成する方法もあります。企業が Adatum フォレストと Fabrikam フォレストの 2 つのフォレストにわたると想定します。
.gif "important") 重要 : |
|---|
| 匿名メール発信を解決するように Exchange サーバーを構成すると、悪意を持つユーザーがリターン アドレスを偽造してメッセージを発信できるようになります。受信者は、本物のメールとスプーフィングされたメールを区別できません。この可能性を最小限に抑えるには、SMTP 仮想サーバーへのアクセスを、Exchange サーバーの IP アドレスに制限します。 |
Adatum ユーザーの連絡先を Fabrikam フォレスト内の表示名に解決するには、次の手順を実行します。
- Adatum フォレストに、Fabrikam フォレストに接続するコネクタを作成します。
- Fabrikam フォレストの受信側ブリッジヘッド サーバーで、SMTP 仮想サーバーへのアクセスを IP アドレスによって制限します。これにより、Adatum フォレストのサーバーだけがこのサーバーにメールを送信できるようになります。
- コネクタをホストする SMTP 仮想サーバーで、[匿名の電子メールの名前解決を行う] の設定を有効にします。
- レジストリ キーを変更して、拡張メッセージ プロパティ (Exch50 プロパティ) がフォレスト間で保持されるようにします。このプロパティが保持されないと、重要なメッセージ情報が失われる可能性があります。
これらの手順が完了すると、Adatum フォレストから Fabrikam フォレストにメールを送信するユーザーはすべて Fabrikam グローバル アドレス一覧内の表示名に解決されます。次に、Fabrikam フォレストに対して手順 1. ～ 3. を繰り返す必要があります。
以下の手順は、次の作業の方法を示しています。
- Adatum フォレストでの Fabrikam へのコネクタのセットアップ
- Fabrikam フォレストにある受信側ブリッジヘッド サーバーへのアクセスの制限
- Adatum の連絡先を Fabrikam フォレストで解決するための、受信側ブリッジヘッド サーバー上の SMTP 仮想サーバーにおける匿名の電子メール解決の有効化
運用環境では、このプロセスを繰り返して、Fabrikam の連絡先を Adatum フォレストで解決するように構成します。
手順 1: 接続元フォレストにコネクタを作成する
最初に接続元フォレストにコネクタを作成する必要があります。詳細な手順については、「接続元フォレストにコネクタを作成する方法」を参照してください。
クロス フォレスト認証に使用されるアカウントを作成する方法の詳細については、Exchange Server 2003 トランスポートおよびルーティング ガイドについてのページの、クロス フォレスト認証に使用するアカウントの作成方法に関する記述を参照してください (このサイトは英語の場合があります)。
Exchange は、fabrikam.com (Fabrikam フォレスト) 宛てのすべてのメールを、このコネクタ経由でルーティングするようになります。
手順 2: 受信側ブリッジヘッド サーバーで IP アドレスを制限する
Adatum フォレスト (接続元フォレスト) にコネクタを作成したら、受信側ブリッジヘッド サーバーへのアクセスを制限する必要があります。Adatum フォレストにある接続元サーバーの IP アドレスのみが、Fabrikam フォレストの受信側ブリッジヘッド サーバーにメールを送信できるようにして、アクセスを制限します。
詳細については、Exchange Server 2003 トランスポートおよびルーティング ガイドについてのページの、受信側ブリッジヘッド サーバーで IP アドレスによってアクセスを制限する方法に関する記述を参照してください (このサイトは英語の場合があります)。
手順 3: SMTP 仮想サーバーで匿名の電子メールを解決する
受信側ブリッジヘッド サーバーへのアクセスを制限したら、このブリッジヘッドの SMTP 仮想サーバーを、匿名の電子メール アドレスを解決するように構成する必要があります。
詳細については、Exchange Server 2003 トランスポートおよびルーティング ガイドについてのページの、匿名の電子メール アドレスを解決するように SMTP 仮想サーバーを構成する方法に関する記述を参照してください (このサイトは英語の場合があります)。
手順 4: レジストリ キーを有効にしてフォレスト間でメッセージ プロパティを保持する
前に説明したように、メッセージがフォレスト間で匿名で送信された場合、そのメッセージに関する拡張メッセージ プロパティは送信されません。1 つの企業でクロス フォレスト シナリオを実装する場合、メッセージに関する情報が失われる可能性があるため、これらの拡張メッセージ プロパティを送信する必要があります。たとえば、拡張 Exchange プロパティである SCL プロパティには、サードパーティ製のソリューションで生成されるスパム規制が含まれます。メールが匿名で送信された場合、このプロパティは送信されません。Adatum フォレストにサードパーティ製のスパム対策ソリューションが展開され、このフォレストで受信したメッセージが Fabrikam フォレストの受信者宛てのものである場合、サードパーティ製のソリューションはメッセージに SCL プロパティをスタンプします。ただし、メッセージが Fabrikam フォレストに配信されるとき、スパム評価を含む拡張プロパティは保持されません。
電子メールを匿名で送信するときに拡張メッセージ プロパティがフォレスト間で送信されるようにするには、受信側ブリッジヘッド サーバーでレジストリ キーを有効にする必要があります。
拡張メッセージ プロパティを受け付けるように Exchange を構成するには、受信側ブリッジヘッド サーバーまたはそのブリッジヘッド上に存在する SMTP 仮想サーバーで、レジストリ キーを有効にします。Exchange サーバーでレジストリ キーを有効にすると、その Exchange サーバー上の SMTP 仮想サーバーはすべて拡張プロパティを受け付けるように構成されます。
匿名接続で拡張メッセージ プロパティを受け付けるための Exchange サーバーの構成
匿名接続で拡張プロパティを受け付けるように Exchange サーバーを構成するには、次の手順を使用します。Exchange サーバーが、クロス フォレスト通信専用のブリッジヘッド サーバーとして機能している場合は、この設定をサーバー レベルで構成できます。この Exchange サーバー上に他の SMTP 仮想サーバーがある場合は、このレジストリ キーを SMTP 仮想サーバー上でのみ設定することを検討します。
.gif "note") 注 : |
|---|
| Exchange サーバーでこのレジストリ キーを有効にすると、その設定は Exchange サーバー上のすべての SMTP 仮想サーバーに適用されます。単一の SMTP 仮想サーバーをこの設定で構成する場合は、その SMTP 仮想サーバーでレジストリ キーを有効にします。 |
.gif "Caution") 注意 : |
|---|
| レジストリの編集を誤ると、オペレーティング システムの再インストールを余儀なくされるような重大な問題が発生する可能性があります。レジストリの編集を誤ったために発生した問題は、解決できない場合があります。レジストリを編集する前に、大切なデータはすべてバックアップしてください。 |
詳細については、Exchange Server 2003 トランスポートおよびルーティング ガイドについてのページの、匿名で送信されるメッセージの拡張プロパティを Exchange サーバーが受け付けるようにする方法に関する記述を参照してください (このサイトは英語の場合があります)。
匿名で送信された拡張メッセージ プロパティを受け付けるための SMTP 仮想サーバーの構成
拡張プロパティを受け付けるように、Exchange サーバー上の SMTP 仮想サーバーを構成するには、次の手順を使用します。
詳細については、Exchange Server 2003 トランスポートおよびルーティング ガイドについてのページの、匿名で送信されるメッセージの拡張プロパティを SMTP 仮想サーバーが受け付けるようにする方法に関する記述を参照してください (このサイトは英語の場合があります)。
インターネット メール ウィザード
Exchange Server Version 5.5 では、インターネット メール ウィザードを使用して、インターネット メールのセットアップを行いました。Exchange 2003 には、Exchange 2000 Server または Exchange Server 2003 でのインターネット メール接続を構成できるインターネット メール ウィザードが実装されています。インターネット メール ウィザードは、主に大規模な企業ほど環境が複雑ではない小規模および中規模の企業向けに設計されています。
ウィザードの指示に従い、インターネット メールを送受信するように Exchange サーバーを構成します。送信インターネット メールに必要な SMTP コネクタが作成され、受信メールを許可するように SMTP 仮想サーバーが構成されます。Exchange サーバーで既に SMTP コネクタをセットアップした場合、または追加の SMTP 仮想サーバーを作成した場合は、サーバーの構成を既定の状態に戻さない限り、インターネット メール ウィザードを実行できません。
| 注 : |
|---|
| インターネット メール ウィザードは、Exchange 2000 Server 以降のバージョンのインターネット メールのみを構成できます。Exchange 2000 より前のバージョンの Exchange を実行している場合でも、これらのサーバーはインターネットにメールを送信したりインターネットからメールを受信したりすることはできますが、インターネット メール ウィザードを使用してインターネット メール用にサーバーを構成することはできません。 |
インターネット メール ウィザードを実行すると、構成変更が正しく行われたかどうかを含め、すべての構成変更を記録したログ ファイル (Exchange Internet Mail Wizard.log) が作成されます。このログ ファイルは、ウィザードを実行するユーザーの My Documents フォルダに保存されます。
ここからは、インターネット メール ウィザードを使用して次のことを行う方法について説明します。
- インターネット メールを送信するための Exchange サーバーの構成
- インターネット メールを受信するための Exchange サーバーの構成
- インターネット メールを送受信するための Exchange サーバーの構成
- インターネット メール用のデュアルホーム Exchange サーバーの構成
インターネット メールを送信するための Exchange サーバーの構成
インターネット メールを送信するように Exchange サーバーを構成すると、選択したサーバーがインターネット メール ウィザードによって送信ブリッジヘッド サーバーとして構成されます。このサーバー上に、指定したインターネット アドレスにメールを送信するためのコネクタが作成されます。
詳細な手順については、「インターネット メール ウィザードを実行して、インターネット メールを送信するようにサーバーを構成する方法」を参照してください。
インターネット メールを受信するための Exchange サーバーの構成
インターネット メール ウィザードの実行後、Exchange サーバーは、指定した SMTP ドメインへのすべてのインターネット メールを許可します。
詳細な手順については、「インターネット メール ウィザードを実行して、インターネット メールを受信するようにサーバーを構成する方法」を参照してください。
インターネット メールを送受信するための Exchange サーバーの構成
インターネット メール ウィザードの実行後、Exchange サーバーは、指定した構成に従ってすべてのインターネット メールを送受信します。
詳細な手順については、「インターネット メール ウィザードを実行して、インターネット メールを送受信するようにサーバーを構成する方法」を参照してください。
インターネット メール用のデュアルホーム Exchange サーバーの構成
インターネット メール ウィザードの実行後、Exchange サーバーは、指定した構成に従ってすべてのインターネット メールを送受信します。
詳細な手順については、「デュアルホーム サーバーでインターネット メール ウィザードを実行する方法」を参照してください。
DSN の診断ログ出力および DSN コード
Exchange 2003 では、配信状態通知 (DSN) に関して次のような機能強化が行われています。
- DSN という新しいログ出力分類項目を使用できます。
- メッセージの流れに関する問題のトラブルシューティングに役立つ、新しい DSN コードが追加されました。
DSN 診断ログの構成
DSN の診断ログを構成できるようになりました。これは配信不能レポート (NDR) とも呼ばれます。
詳細な手順については、「DSN の診断ログを構成する方法」を参照してください。
Exchange Server 2003 で使用可能な DSN コード
次の表は、Exchange 2003 に実装されているトランスポートおよびルーティング用の DSN メッセージです。
Exchange 2003 で使用できる新しい配信状態通知
| DSN コード | 原因 | 解決方法 |
|---|---|---|
4.2.2 |
Exchange 2000 では、受信者のメールボックスが格納域の制限を超えたときにこの配信状態通知が生成されます。 Windows 2000 および Microsoft Windows Server™ 2003 では、このメッセージは、ドロップ ディレクトリ (配信のためにメッセージが置かれるディレクトリ) の格納域サイズが SMTP 仮想サーバーのディスク クォータを超えたときに生成されます。SMTP 仮想サーバーのディスク クォータは、その仮想サーバー上の最大メッセージ サイズの 11 倍です。最大サイズが指定されていない場合、ディスク クォータの既定値は 22 MB になります。ディスク領域がクォータの最大メッセージ サイズを超えていない場合、またはディスク領域が 2 MB に達し、最大メッセージが定義されていない場合、Exchange は受信メッセージがディスク クォータを超えると想定し、DSN を発行します。 |
メールボックス格納域とキュー格納域のクォータ制限を確認します。 |
4.4.9 |
一時的なルーティング エラー、または正しくないルーティング構成を示します。考えられる原因は次のとおりです。
|
ルーティングでこれらの状況が検出され、Exchange が DSN を返します。
|
5.3.0 |
Exchange 2003 は、メッセージ転送エージェント (MTA) を使用せずに動作できます。メールが誤って MTA に送信された場合、Exchange は送信者にこの DSN を返します。この状況は、MTA サービスを無効にし、MTA/Store Driver を無効にするための特定のレジストリ設定を使用した場合にのみ適用されます。既定の構成では、誤ってルーティングされたメールは MTA キューに残されます。 |
ルーティング トポロジを確認します。Winroute ツールを使用して、サーバーとルーティング グループの間でルートが正しくレプリケートされていることを確認します。 |
5.7.1 |
一般的なアクセス拒否です。送信者のアクセスが拒否されました。メッセージの送信者に、配信を完了するために必要な特権がありません。 考えられる原因は次のとおりです。
|
連絡先に対するシステム特権と属性を確認して、メッセージを再送信します。また、その他の考えられる既知の問題については、Exchange 2000 Service Pack 1 以降を実行します。Exchange 2003 で、配布グループに対するアクセス許可を調べ、制限された配布グループであるかどうかを確認します。 |
X.400 (MTA) および SMTP キュー ディレクトリの場所の移動
Exchange 2003 では、SMTP 仮想サーバーおよび X.400 プロトコルのキュー ディレクトリの場所を変更できます。
詳細な手順については、「X.400 (MTA) キュー データを移動する方法」と「SMTP キュー データを移動する方法」を参照してください。
接続フィルタ
Exchange Server 2003 は、ブロック リストに基づいた接続フィルタをサポートします。既知の迷惑メールの送信元、ダイヤルアップ ユーザー アカウント、および第三者中継用のサーバーに関して、これらの IP アドレスの一覧を提供する外部のサービスがあります。接続フィルタはこれらのサービスを使用します。接続フィルタは、サード パーティ製のコンテンツ フィルタ製品に対応しています。この機能を使用することによって、受信した IP アドレスをブロック リスト プロバイダの一覧と照合し、目的のカテゴリを基にフィルタを適用できます。ブロック リスト プロバイダの一覧に一致が見つかった場合、SMTP が RCPT TO コマンドに対して "550 5.x.x" エラーを発行し、送信者にはカスタマイズされたエラー応答が発行されます。RCPT TO コマンドは、指定されたメッセージ受信者を識別するために接続元サーバーが発行する SMTP コマンドです。また、接続フィルタは複数使用でき、各フィルタが適用される優先順位を設定できます。
接続フィルタによって以下を行うことができます。
- ブロック リスト サービス プロバイダで以下のものに対する確認を行う、接続フィルタ処理のルールのセットアップ。
- 不要な商用メールの既知の送信者の IP アドレス
- 第三者中継用に構成されたサーバー
- ダイヤルアップ ユーザーのアカウント一覧
- グローバル許可一覧およびグローバル拒否一覧の構成。グローバル許可一覧は、常に電子メールを受け付ける送信元の IP アドレス一覧です。グローバル拒否一覧は、常に電子メールを拒否する送信元の IP アドレス一覧です。グローバル許可一覧とグローバル拒否一覧は、ブロック リスト サービス プロバイダの使用の有無に関係なく使用することができます。
- すべての接続フィルタ処理のルールに対する例外としての受信者アドレスの構成。受信者アドレスを、すべての接続フィルタ処理のルールに対する例外として構成できます。このアドレスにメールが送信されると、送信者がブロック リストに記載されている場合でも、メールは自動的に受け付けられます。
接続フィルタ処理のルールのしくみ
接続フィルタ処理のルールを作成すると、SMTP はこのルールを使用して、サード パーティ製のブロック リスト サービスによって提供される一覧に対する DNS 参照を実行します。接続フィルタは、受信 IP アドレスをサード パーティのブロック リストと照合します。ブロック リスト プロバイダは、次の 2 つの応答のいずれかを発行します。
- ホストが見つからない IP アドレスが、ブロック リストに記載されていないことを示します。
- 127.0.0.x IP アドレスに対する一致が攻撃者の一覧に記載されていることを示す応答状態コードです。x は、ブロック リスト プロバイダによって異なります。
受信 IP アドレスがブロック リストに見つかった場合、SMTP は RCPT TO コマンドに応答して 5.x.x エラーを返します。RCPT TO コマンドは、指定されたメッセージ受信者を識別するために接続元サーバーが発行する SMTP コマンドです。
送信者に返される応答はカスタマイズできます。また、ブロック リスト プロバイダには通常さまざまな攻撃者の分類が含まれているため、拒否する一致を指定できます。ほとんどのブロック リスト プロバイダは、3 つの種類の攻撃者について調べます。
- 不要な商用メールの送信元。これらの一覧は、不要な商用メールをスキャンして、送信元アドレスを一覧に追加することで生成されます。
- 既知の第三者中継サーバー。これらの一覧は、インターネット上の第三者中継 SMTP サーバーを識別することによって生成されます。第三者中継サーバーの最も一般的な理由は、システム管理者による構成の誤りです。
- ダイヤルアップ ユーザーの一覧。これらの一覧は、ダイヤルアップ アクセスを行う IP アドレスを含む既存のインターネット サービス プロバイダ (ISP) の一覧、またはダイヤルアップ接続の可能性を示すアドレスの調査を基に作成されます。
ブロック リスト プロバイダによる攻撃元 IP アドレスの照合方法
接続フィルタをセットアップした後、組織に電子メール メッセージが送信されると、Exchange はブロック リスト プロバイダに問い合わせます。プロバイダは、DNS で A (ホスト) レコードが存在するかどうかを確認します。Exchange は、この情報を特定の形式で照会します。たとえば、接続元アドレスが 192.168.5.1 で、ブロック リスト プロバイダの組織が contoso.org である場合、Exchange は次のレコードが存在するかどうかをを照会します。
<reverse IP address of the connecting server>.<dns name for the block list organization> IN A 127. 0.0.x
この場合は、次のようになります。
1.5.168.192..contoso.org
この IP アドレスがプロバイダの一覧に見つかった場合、プロバイダは攻撃元 IP アドレスと攻撃の種類を示す 127.0.0.x の状態コードを返します。すべてのブロック リスト プロバイダが応答コード 127.0.0.x を返します。x は、攻撃の種類を示します。この数字は、ブロック リスト プロバイダによって異なります。
ブロック リスト プロバイダの応答コードについて
前に説明したように、ブロック リスト プロバイダで一致が見つかった場合、プロバイダは常に 127.0.0.x の状態コードを返します。状態コードは、明示的なリターン コードまたはビット マスクのいずれかで、多機能的な戻り値です。ブロック リスト プロバイダが値を返す場合、フィルタの対象とする値を指定できます。ただし、ブロック リスト プロバイダがビット マスクを返す場合、フィルタの対象とする一致を指定するにはビット マスクのしくみを理解する必要があります。
ビット マスクは、エントリに対して特定のビットが設定されていることを確認するために使用される方法です。ビット マスクは、値の範囲を確認するサブネット マスクとは逆に、特定のビット値を確認するという点で従来のマスクとは異なります。次の例について考えます。
ブロック リストで一致が見つかるたびに、ブロック リスト プロバイダが次の表に示す状態コードを返すとします。
ブロック リストの状態コードの例
| 分類 | 返される状態コード |
|---|---|
迷惑電子メールの既知の送信元 |
127.0.0.3 |
ダイヤルアップ ユーザー アカウント |
127.0.0.2 |
既知の中継サーバー |
127.0.0.4 |
ただし、IP アドレスが 2 つの一覧に含まれている場合、ブロック リスト プロバイダは最後のオクテットの値を加算します。したがって、IP アドレスが既知の中継サーバーの一覧と迷惑電子メールの既知の送信元の一覧の両方にある場合、ブロック リスト プロバイダは 127.0.7 の状態コードを返します。7 は、不要な商用メールの既知の送信元に対して返される値と、既知の中継サーバーに対して返される値の最後のオクテットを加算した値です。
不要な商用メールの既知の送信元のみにフィルタを適用するには、0.0.0.3 のビット マスク値を入力します。ブロック リストは、可能性のあるすべての値 (この場合は、127.0.0.3、127.0.0.5、127.0.0.7、および 127.0.0.9) にフィルタを適用します。
次の表に、状態コードの例と、それぞれ関連付けられているビット マスク値を示します。
ブロック リストの状態コードと対応するビット マスクの例
| 分類 | 返される状態コード | ビット マスク |
|---|---|---|
迷惑電子メールの既知の送信元 |
127.0.0.3 |
0.0.0.3 |
ダイヤルアップ ユーザー アカウント |
127.0.0.2 |
0.0.0.2 |
既知の中継サーバー |
127.0.0.4 |
0.0.0.4 |
既知の中継サーバーとダイヤルアップ ユーザー アカウント |
127.0.0.6 |
0.0.0.6 |
既知の中継サーバーとダイヤルアップ ユーザー アカウントという分類では、ビット マスク 0.0.0.6 は、IP アドレスが既知の中継サーバーの一覧とダイヤルアップ ユーザー アカウントの一覧の両方にある場合にのみ、一致を返します。IP アドレスが 2 つの一覧のどちらかにしかない場合、一致は返されません。ビット マスクを使用して、複数の一覧にある単一の一致を確認することはできません。
| 注 : |
|---|
| ビット マスクは単一の値に対するチェックのみを行います。IP アドレスが 2 つの一覧にあるときに返されるマスク値を設定する場合、そのビット マスクは両方の一覧にある IP アドレスのみに一致します。IP アドレスが 2 つの一覧のいずれかにあるかどうかを確認する場合は、これらの設定の状態コードを入力します。 |
接続フィルタ処理のルールに対する例外の指定
ブロック リストに記載されているかいないかにかかわらず、特定の受信者へのメッセージ配信を許可することができます。これは、正当な組織がポストマスタ アカウントに連絡して管理者と通信できるようにする場合に役立ちます。たとえば、正当な企業のサーバーが第三者中継を許可するように誤って構成されている場合、この企業からユーザーに送信される電子メールはブロックされます。ただし、組織のポストマスタ アカウントへのメッセージ配信を許可するように接続フィルタを構成した場合、ブロックされた企業の管理者はポストマスタ アカウントにメールを送信して、状況を伝えたり、メールが拒否された理由を問い合わせたりすることができます。
接続フィルタの有効化
接続フィルタを有効にするには、次の手順を実行します。
- [メッセージ配信のプロパティ] ダイアログ ボックスの [接続フィルタ] タブを使用して、接続フィルタを作成します。
- SMTP 仮想サーバー レベルでフィルタを適用します。
- SP2 の新機能 : 接続フィルタの対象外とする、内部ネットワークのサーバーを指定します。
各手順について、以下に詳しく解説します。
手順 1: 接続フィルタを構成する
接続フィルタを構成にするには、次の作業を行います。
- グローバル許可一覧およびグローバル拒否一覧の作成
- 接続フィルタ処理のルールの作成
- 接続フィルタ処理のルールに対する例外の作成
グローバル許可一覧およびグローバル拒否一覧の作成
接続フィルタを使用して、グローバル許可一覧およびグローバル拒否一覧を作成できます。これらの一覧を使用すると、ブロック リスト サービス プロバイダの使用の有無に関係なく、特定の IP アドレスから送信されたメールを常に許可または拒否できます。グローバル許可一覧に記載されている IP アドレスは自動的に受け付けられ、接続フィルタ処理のルールはすべて無視されます。同様に、グローバル拒否一覧に記載されている IP アドレスは自動的に拒否されます。
グローバル許可一覧のエントリは、グローバル拒否一覧のエントリより優先されます。Exchange は、グローバル許可一覧を確認してからグローバル拒否一覧を確認します。したがって、特定のサブネットおよびマスクからの接続を拒否し、同じ範囲内の特定の IP アドレスからの接続だけを許可する場合は、次の操作を行います。
- 接続を許可する IP アドレスをグローバル許可一覧に入力します。
- 接続を拒否する IP アドレスの範囲を表すサブネットおよびマスクを、グローバル拒否一覧に入力します。
グローバル許可一覧に追加した接続元 IP アドレスが Exchange サーバーに接続しようとすると、Exchange はまずグローバル許可一覧を確認します。Exchange によってこの IP アドレスが一覧で見つけられると、接続が許可されます。Exchange はそれ以上の接続フィルタによる確認を行いません。
詳細については、Exchange Server 2003 トランスポートおよびルーティング ガイドについてのページの、グローバル許可一覧を作成する方法とグローバル拒否一覧を作成する方法に関する記述を参照してください (このサイトは英語の場合があります)。
接続フィルタ処理のルールの作成
接続フィルタのルールを作成する方法の詳細については、Exchange Server 2003 トランスポートおよびルーティング ガイドについてのページの、接続フィルタを作成する方法に関する記述を参照してください (このサイトは英語の場合があります)。
接続フィルタ処理のルールに対する例外を作成できます。接続している IP アドレスがブロック リストに記載されている場合でも、特定の受信者 (ポストマスタなど) へのメッセージ配信を許可することができます。
詳細については、Exchange Server 2003 トランスポートおよびルーティング ガイドについてのページの、接続ルールに対する例外を指定する方法に関する記述を参照してください (このサイトは英語の場合があります)。
手順 2: 接続フィルタを適切な SMTP 仮想サーバーに適用する
接続フィルタを作成したら、適切な SMTP 仮想サーバーに適用する必要があります。通常、接続フィルタは、受信インターネット メールを受け付けるゲートウェイ サーバー上に存在する SMTP 仮想サーバーに適用します。接続フィルタを SMTP 仮想サーバーに適用するには、次の手順を使用します。
詳細については、Exchange Server 2003 トランスポートおよびルーティング ガイドについてのページの、接続フィルタを SMTP 仮想サーバーに適用する方法に関する記述を参照してください (このサイトは英語の場合があります)。
SP2 の新機能 : 手順 3: 接続フィルタの対象外とするサーバーの指定
Exchange Server 2003 SP2 では、ネットワーク境界の背後での接続フィルタを有効にすることができます。これを行うには、[メッセージ配信のプロパティ] ダイアログ ボックスの [全般] タブで、IP アドレスの検証の対象外とする、内部ネットワークのサーバーの IP アドレスを指定します。
個々の IP アドレスまたは IP アドレスのグループを指定できます。受信 SMTP メールを処理する組織内のサーバーをすべて含める必要があります。また、送信者 ID フィルタおよび接続フィルタが設定されているサーバーにメールをルーティングするサーバーもすべて含める必要があります。SMTP メールを処理するサーバーが境界上に配置されている場合は、これらのサーバーの境界 IP アドレスをすべて含める必要があります。
送信者 ID フィルタまたは接続フィルタが設定されているサーバーで受信された電子メール メッセージの IP アドレスがこの一覧にある場合、Exchange Server はその IP アドレスの送信者 ID フィルタと接続フィルタの検証をスキップします。一覧には IP アドレスを 196 件まで追加できます。
内部ネットワークのサーバーを指定する方法については、Exchange Server 2003 SP2 オンライン ヘルプの、接続フィルタ用の IP アドレス構成データの指定に関する記述を参照してください。
受信者のフィルタ
受信者のフィルタを使用して、すべての無効な受信者宛ての電子メールをブロックすることができます。また、受信者が有効か無効かにかかわらず、受信者のフィルタの一覧で指定されるすべての受信者への電子メールもブロックできます。
受信者のフィルタでは、Active Directory 参照を基に受信メールで指定された受信者をフィルタ処理して、無効な受信者が宛先になっているメールをブロックします。次の条件を基にしてメールにフィルタを適用できます。
- 受信者が Active Directory に存在していないかどうか。
- 送信者が適切なアクセス許可を持っていないかどうか。
これらの条件に一致する受信メールはすべて拒否され、SMTP 仮想サーバーは SMTP セッション中に 550 5.x.x エラーを返します。
| 注 : |
|---|
| Exchange が行うのは、Active Directory 参照の実行と、特権のあるドメイン宛ての受信メールに対する無効な受信者のブロックのみです。この設定は、受信者ポリシーで構成されます。 |
また、組織内の指定した (有効または無効な) 電子メール アドレスに送信されるメッセージにフィルタを適用するように受信者のフィルタを構成することもできます。指定した受信者にメッセージが送信されると、Exchange は、SMTP セッション中に 5.x.x レベルのエラーを返します。
既定では、Exchange はすべての (有効または無効な) 受信者宛てのメールを受け付け、すべての無効な受信者について配信不能レポート (NDR) を送信します。また、迷惑メールは一般的に無効なアドレスから送信されるため、Exchange は存在しない送信者への NDR の再配信を試行し、それによってリソースの消費量が増加します。受信者のフィルタを有効にすると無効な受信者にフィルタが適用されるため、Exchange がこのような形でリソースを消費しなくなります。ただし、受信者のフィルタで Active Directory 内の受信者を解決できるようにすると、悪意を持つ送信者が有効な電子メール アドレスを解決できるようになる可能性があります。これは、有効な受信者と無効な受信者に対して SMTP セッションが異なる応答を発行するためです。
| 注 : |
|---|
| 受信者のフィルタ ルールは、匿名接続にのみ適用されます。認証ユーザーおよび Exchange サーバーはこれらの検証を無視します。 |
受信者のフィルタの有効化
受信者のフィルタを有効にするには、次の手順を実行します。
- [メッセージ配信のプロパティ] ダイアログ ボックスの [受信者のフィルタ] タブを使用して、受信者のフィルタを作成します。
- SMTP 仮想サーバー レベルでフィルタを適用します。
各手順について、以下に詳しく解説します。
手順 1: 受信者のフィルタを作成する
最初に、受信者のフィルタを作成する必要があります。詳細については、Exchange Server 2003 トランスポートおよびルーティング ガイドについてのページの、受信者フィルタを作成する方法に関する記述を参照してください (このサイトは英語の場合があります)。
手順 2: 適切な SMTP 仮想サーバーに受信者のフィルタを適用する
受信者のフィルタを作成した後、その受信者のフィルタを適切な SMTP 仮想サーバーに適用する必要があります。通常、受信者のフィルタは、受信インターネット メールを受け付けるゲートウェイ サーバー上に存在する SMTP 仮想サーバーに適用します。受信者のフィルタを SMTP 仮想サーバーに適用するには、次の手順を使用します。
詳細については、Exchange Server 2003 トランスポートおよびルーティング ガイドについてのページの、受信者のフィルタを SMTP 仮想サーバーに適用する方法に関する記述を参照してください (このサイトは英語の場合があります)。
SP2 の新機能 : 送信者 ID フィルタ
Exchange Server 2003 SP2 では、送信者 ID フィルタを使用できます。送信者 ID は、迷惑な商用電子メール (UCE) およびフィッシングからコンピュータを保護するための電子メール業界標準です。特に、送信者 ID フレームワークは、電子メール メッセージの送信者を検証することによって、電子メール ドメインのスプーフィングを低減し、電子メール フィッシングに対する保護を強化するために作成されたプロトコルです。送信者 ID の詳細については、送信者 ID についての Web サイトを参照してください (このサイトは英語の場合があります)。
送信者 ID の構成
以下の概要では、Exchange Server 2003 SP2 で送信者 ID フィルタを構成する際に実行する必要がある 3 つの手順について説明します。
- [メッセージ配信のプロパティ] ダイアログ ボックスの [送信者 ID フィルタ] タブで次のオプションのいずれかを選択し、送信者 ID の検証に失敗したメッセージをサーバーでどのように処理するかを指定します。
- [許可 (以後のスパム対策処理用に、送信者 ID の状態がメッセージに添付されます)] を選択すると、送信者 ID フィルタは検証結果をメッセージにスタンプします。その後、インテリジェント メッセージ フィルタなどの別のスパム対策プログラムによる処理が行われます。これは既定の設定です。
- [削除 (メッセージは受け入れられた後に削除されます。送信者に NDR が送信されることはありません)] を選択すると、送信者 ID フィルタはメールを受け入れた後に削除します。ユーザーに配信不能レポート (NDR) は送信されません。
- [拒否 (メッセージは受け入れられません。送信側は NDR を生成する必要があります)] を選択すると、送信者 ID フィルタは SMTP プロトコル レベルでメールを拒否し、ユーザーに NDR メッセージを発行します。NDR の生成には送信サーバーが使用されます。
- [メッセージ配信のプロパティ] ダイアログ ボックスの [全般] タブで、IP アドレスの検証の対象外とする、内部ネットワークのサーバーの IP アドレスを指定します。個々の IP アドレスまたは IP アドレスのグループを指定できます。受信 SMTP メールを処理する Exchange 組織内のサーバーをすべて含める必要があります。また、送信者 ID フィルタおよび接続フィルタが設定されているサーバーにメールをルーティングするサーバーもすべて含める必要があります。SMTP メールを処理するサーバーが境界上に配置されている場合は、これらのサーバーの境界 IP アドレスをすべて含める必要があります。送信者 ID フィルタまたは接続フィルタが設定されているサーバーで受信された電子メール メッセージの IP アドレスがこの一覧にある場合、Exchange Server はその IP アドレスの送信者 ID フィルタと接続フィルタの検証をスキップします。一覧には IP アドレスを 196 件まで追加できます。
- SMTP 仮想サーバーで送信者 ID を有効にします。送信者 ID フィルタのオプションを構成した後で、Exchange 組織内の SMTP 仮想サーバーで送信者 ID フィルタを有効にする必要があります。
これらの各操作を実行する方法の詳細については、Exchange Server 2003 SP2 オンライン ヘルプの「送信者 ID フィルタの構成」を参照してください。
SP2 の新機能 : インテリジェント メッセージ フィルタ
Exchange Server 2003 SP2 では、インテリジェント メッセージ フィルタは Exchange Server 2003 SP2 のインストール時にインストールされ、使用できる状態になります。
| 注 : |
|---|
| Exchange Server 2003 のインストール プログラムによってインテリジェント メッセージ フィルタが実行中であることが検出されると、Exchange Server 2003 SP2 のインストールを続行する前にフィルタをアンインストールするかどうかを確認するメッセージが表示されます。 |
インテリジェント メッセージ フィルタを使用すると、スパムとしても知られる迷惑な商用電子メール (UCE) をゲートウェイ SMTP 仮想サーバーで阻止できます。ゲートウェイ SMTP 仮想サーバーは、インターネット電子メールを受け入れる SMTP 仮想サーバーです。
インテリジェント メッセージ フィルタの詳細については、Exchange インテリジェント メッセージ フィルタ についての Web サイトを参照してください (このサイトは英語の場合があります)。
インテリジェント メッセージ フィルタの構成
以下の概要では、Exchange Server 2003 SP2 でインテリジェント メッセージ フィルタを構成する際に実行する必要がある手順について説明します。
- [メッセージ配信のプロパティ] ダイアログ ボックスの [インテリジェント メッセージ フィルタ] タブにあるオプションを使用して、インテリジェント メッセージ フィルタを作成します。異なる SCL レベルを持つ電子メール メッセージをどのようにインテリジェント メッセージ フィルタが処理するかを決定するための、2 つのしきい値を設定できます。1 つはゲートウェイのしきい値で、もう 1 つはメールボックス ストアのしきい値です。ゲートウェイのしきい値では、設定したしきい値を超えた際にメッセージに対して行う処理を関連付けます。
- メッセージの SCL レベルがゲートウェイのしきい値を超えている場合、指定した処理がそのメッセージに対して実行されます。これらのオプションには、[アーカイブ]、[削除]、[何もしない]、および [拒否] があります。
- メッセージの SCL レベルがゲートウェイのしきい値以下であれば、そのメッセージは受信者の Exchange メールボックス ストアに送信されます。Exchange メールボックス ストアでは、メッセージの SCL レベルがメールボックス ストアのしきい値を超えている場合、そのメッセージをユーザーの受信トレイではなく、迷惑メール フォルダに配信します。
- SMTP 仮想サーバーでインテリジェント メッセージ フィルタを有効にします。インテリジェント メッセージ フィルタのオプションを構成した後で、Exchange 組織内の SMTP 仮想サーバーでインテリジェント メッセージ フィルタを有効にする必要があります。
これらの各操作を実行する方法の詳細については、Exchange Server 2003 SP2 オンライン ヘルプの「インテリジェント メッセージ フィルタの構成」を参照してください。
SP2 で更新された機能 : 有効なフィルタの適用方法について
Exchange Server 2003 は、以下のフィルタをサポートします。
- 仮想サーバー単位の IP 制限
- 接続フィルタ
- 受信者のフィルタ
- 送信者のフィルタ
- 送信者 ID フィルタ
- インテリジェント メッセージ フィルタ
接続フィルタ、受信者のフィルタ、送信者のフィルタ、送信者 ID フィルタ、インテリジェント メッセージ フィルタはすべて [メッセージ配信のプロパティ] で構成しますが、各 SMTP 仮想サーバー上で有効にする必要があります。これに対し、IP 制限は、各 SMTP 仮想サーバー上で直接構成します。
ここでは、これらのフィルタが構成されて有効にされている場合、SMTP セッション中にどのような順序で確認されるかについて説明します。フィルタと IP 制限は、次の方法で確認されます。
| 注 : |
|---|
| このセクションは更新されて、Exchange Server 2003 SP2 を実行するサーバーでのスパム対策処理に関する情報を提供するようになりました。この例では、Exchange Server 2003 SP2 がゲートウェイ コンピュータにインストールされていることを前提にしています。 |
- SMTP クライアントが、SMTP 仮想サーバーへの接続を試みます。
- 接続元のクライアントの IP アドレスが、SMTP 仮想サーバーの [プロパティ] の [アクセス] タブで構成される SMTP 仮想サーバーの IP 制限と比較して確認されます。
- 接続元の IP アドレスが制限されている IP の一覧に記載されている場合、接続は直ちに切断されます。
- 接続元の IP アドレスが制限されている IP の一覧に記載されていない場合、接続は許可されます。
- SMTP クライアントが、EHLO コマンドまたは HELO コマンドを発行します。
- SMTP クライアントが、次のような MAIL FROM: コマンドを発行します。
MAIL FROM: dylanm@contoso.com - SMTP クライアントの IP アドレスが、Exchange システム マネージャの [メッセージ配信のプロパティ] ダイアログ ボックスの [接続フィルタ] タブで構成されるグローバル許可一覧と比較して確認されます。
- 接続元の IP アドレスがグローバル許可一覧に記載されている場合、グローバル拒否一覧は確認されません。手順 7. に進みます。
- 接続元の IP アドレスがグローバル許可一覧に記載されていない場合は、手順 6. と 7. が実行されます。
- SMTP クライアントの IP アドレスが、Exchange システム マネージャの [メッセージ配信のプロパティ] ダイアログ ボックスの [接続フィルタ] タブで構成されるグローバル拒否一覧と比較して確認されます。
- SMTP クライアントの IP アドレスがグローバル拒否一覧に記載されている場合、接続は拒否されます。
- SMTP クライアントの IP アドレスがグローバル拒否一覧に記載されていない場合、セッションは続行されます。
- 送信者のフィルタが、MAIL FROM コマンドで指定された送信者を、Exchange システム マネージャの [メッセージ配信のプロパティ] ダイアログ ボックスの [送信者のフィルタ] タブで構成される、ブロックされる送信者の一覧と比較して確認します。
- 送信者がブロックされる送信者の一覧に記載されている場合は、送信者のフィルタの構成方法に応じて、次の 2 つのいずれかの処理が実行されます。
- 送信者のフィルタが接続を切断するように構成されている場合、接続は切断されます。
- 送信者のフィルタが送信者に通知せずにメッセージを受け付けるように構成されている場合、セッションは続行されます。ただし、メールは無効なメール ディレクトリに送信され、意図された受信者には配信されません。 - 送信者が送信者のフィルタの一覧に記載されていない場合、SMTP 仮想サーバーは次のような応答を発行します。
250 2.1.0 dylanm@contoso.com...Sender OK
- 送信者がブロックされる送信者の一覧に記載されている場合は、送信者のフィルタの構成方法に応じて、次の 2 つのいずれかの処理が実行されます。
- 接続している SMTP サーバーが、次のような RCPT TO コマンドを発行します。
RCPT TO: kim@example.com - 接続フィルタ処理のルールが、接続元の IP アドレスをブロック リスト サービス プロバイダによって提供されるブロック リストと比較して確認します。
- SMTP クライアントの IP アドレスが許可一覧に記載されている場合、接続フィルタの処理ルールは無視されます。手順 10. に進みます。
- SMTP クライアントの IP アドレスが、ブロック リスト サービス プロバイダのブロック リストに記載されている場合は、SMTP 仮想サーバーがエラー コードを返し、さらに接続フィルタ処理のルール用に構成されているカスタマイズされたエラー メッセージを送信します。
- SMTP クライアントの IP アドレスがブロック リスト サービス プロバイダのブロック リストに記載されていない場合、セッションは続行されます。
- 接続フィルタが、接続フィルタの例外一覧に、指定された受信者が記載されているかどうかを確認します。
- 受信者が一覧に記載されている場合、通信は許可され、RCPT TO コマンドに対して他の確認は適用されません。手順 13. に進みます。
- 受信者が例外一覧に記載されていない場合は、他のフィルタに対して受信者が確認されます。
- 受信者が接続フィルタ内で構成された例外一覧に記載されていない場合、受信者は、受信者のフィルタ内で構成されているすべてのブロックされる受信者と比較して確認されます。
- 受信者がブロックされる受信者の場合、SMTP 仮想サーバーは無効な受信者エラーを返します。
- 受信者がブロックされる受信者ではない場合は、セッションが続行されます。
- 受信者がブロックされる受信者ではない場合、指定された受信者が Active Directory 内に存在していることを確認するために Active Directory が調べられます。
- 指定された受信者が Active Directory 内に存在する有効な受信者ではない場合、SMTP 仮想サーバーは無効な受信者エラーを返します。
- 受信者が Active Directory 内に存在する有効な受信者の場合、セッションが続行されます。
- RCPT TO コマンドで指定されているその他の各受信者について、手順 10. ～ 12. が適用されます。
- 接続しているサーバーが、次のような DATA コマンドを発行します。
DATA
To: Kim Akers
From: dylanm@contoso.com<Dylan Miller>
Subject: Mail Message - 次に、送信者のフィルタが、From で指定されたアドレスがブロックされる送信者と一致しないことを確認します。
- DATA コマンドで指定された送信者がブロックされる送信者の場合は、次の 2 つのいずれかの処理が実行されます。
- 送信者のフィルタが接続を切断するように構成されている場合は、SMTP 仮想サーバーが 5.1.0 "Sender Denied" エラーを返し、接続を切断します。
- 送信者のフィルタが送信者に通知せずにメッセージを受け付けるように構成されている場合、セッションは続行されます。ただし、メールは無効なメール ディレクトリに送信され、意図された受信者には配信されません。 - DATA コマンドで指定された送信者がブロックされる送信者ではない場合、メッセージは受け付けられ、配信のためにキューに入れられます。
- DATA コマンドで指定された送信者がブロックされる送信者の場合は、次の 2 つのいずれかの処理が実行されます。
- メッセージは送信者 ID の検証によって処理されます。
- メッセージはインテリジェント メッセージ フィルタによって処理されます。
SMTP 仮想サーバーへの発信を制限する機能の強化
Exchange Server 2003 では、標準的な Windows 2000 Server または Windows Server 2003 の随意アクセス制御リスト (DACL) を使用して、SMTP 仮想サーバーへの発信を限られた数のセキュリティ プリンシパルに制限することができます。これにより、仮想サーバーにメールを発信できるユーザーのグループを指定することができます。
| 注 : |
|---|
| インターネット メールを受け付ける SMTP 仮想サーバー上では発信を制限しないでください。 |
詳細については、Exchange Server 2003 トランスポートおよびルーティング ガイドについてのページの、セキュリティ グループを基にして SMTP サーバーへの発信を制限する方法に関する記述を参照してください (このサイトは英語の場合があります)。
SMTP 仮想サーバーでの中継を制限する機能の強化
Exchange 2003 では、標準的な Windows 2000 の随意アクセス制御リスト (DACL) を使用して、中継を限られた数のセキュリティ プリンシパルに制限できます。これにより、仮想サーバーを中継に使用できるユーザーのグループを指定することができます。
仮想サーバーでの中継を制限する機能は、あるユーザー グループにインターネットへのメールの中継を許可し、別のグループの中継特権を拒否する場合に便利です。
詳細については、Exchange Server 2003 トランスポートおよびルーティング ガイドについてのページの、セキュリティ グループを基にして中継を制限する方法に関する記述を参照してください (このサイトは英語の場合があります)。