Exchange Queue & Aセキュリティで保護された電子メール プロトコル、不可解なスパムなど
Nino Bilic and Scott Landry
このコラムの一部は、Windows Server 2008 のプレリリース版を基にしています。ここに記載されている情報は変更される可能性があります。
Q Secure SMTP を使用したいのですが、ポート 465 で SMTP をリッスンするように Exchange Server を構成するにはどうすればよいでしょうか。
A 残念ですが、ご希望を実現する方法はありません。ポート 465 でリッスンするように SMTP 仮想サーバーや SMTP 受信コネクタを構成することはできますが、それでは Secure SMTP (SMTPS) を使用するという目的は達成できません。
なぜでしょうか。では、少しさかのぼって考えてみましょう。SSL には、明示的な SSL と暗黙的な SSL という 2 つの種類があります。最初のうちは、ほとんどの SSL が暗黙的でした。つまり、SSL 専用のポートが使用されていたということです。たとえば、HTTP では既定でポート 80 が使用されますが、HTTPS (HTTP with SSL) ではポート 443 が使用されます。数年前、インターネット業界では、SSL に専用のポートを使用すべきではないという判断が下されました。こうして、明示的な SSL が生まれました。
Netscape では既に 465 が SMTPS のポートとして使用されていましたが、Exchange Server の SMTP では SSL 機能が提供されていませんでした。しかし、Exchange チームは、クライアントとサーバーで平等に使用できるという明示的な SSL の利点を認め、SMTP で明示的な SSL をサポートすることを決めました。
SMTP の明示的な SSL では、STARTTLS ESMTP コマンドを使用することによって、既存のソケットのセキュリティ保護を要求します。他のほとんどの SMTP サーバーおよびクライアント ベンダでは STARTTLS コマンドも実装されていたため、公式のインターネット標準ではないポート 465 をサポートする必要はほとんどありませんでした。
今日まで、Exchange Server のどのバージョンの SMTP でも暗黙的な SSL はサポートされていません。ポート 465 でリッスンするよう Exchange 受信コネクタや SMTP 仮想サーバーに指定しても、暗黙的な SSL を使用することはできません。このため、ポート 25 で STARTTLS がサポートされているクライアントを使用する必要があります。ポート 25 を使用できない場合、次の選択肢はポート 587 です。このポートは、クライアントの SMTP 送信で標準的に使用されているポートです。最近では、ポート 25 で STARTTLS がサポートされていないクライアントはあまり存在しなくなったため、暗黙的な SSL のサポートを追加する必要は生じていません。
ところで、Exchange の POP3 および IMAP4 プロトコルでは、これまで暗黙的な SSL がサポートされてきました。しかし、Exchange Server 2007 では、これら 2 つのプロトコルでも明示的な SSL がサポートされるようになりました。この新しい標準をサポートしているクライアントはまだ少ないため、しばらくは暗黙的な SSL もサポートされる予定です。
Q 多くのドメインのキューに大量のメールが格納されていますが、どのユーザーからもメールは送信されていません。何が起きているのでしょうか。またどのようにしてこの現象を回避すればよいでしょうか。
A あなただけではなく、インターネット上のサーバーを管理しているだれもが、この問題に遭遇する可能性があります。基本的に、考えられる原因は 2 つあります。1 つは、なんらかの方法でサーバーの第三者中継が許可された可能性があります (support.microsoft.com/kb/304897 を参照)。しかし、今回の場合は当然そのような操作は行っていないはずです (Exchange Server 2000 以降、第三者中継は既定で無効になっています)。このため、配信不能レポート (NDR) スパムと呼ばれる攻撃を受けている可能性があります。多くの場合、スパム送信者が迷惑メール (UCE) を送信する際の送信先は、ドメイン内に存在しないアドレスです。サーバーは指定されたユーザーが存在しないことをスパム送信者に通知しようとしますが、当然その返信先は、スパム送信者がスプーフィングしたアドレスです。スパム送信者は、無効なアドレスをスプーフィングしている (この場合、NDR はタイムアウトするまでしばらくサーバー上に残ります) か、サーバーで生成された NDR の添付ファイルとして、そのサーバーから別のドメインにスパムを代理で送信させようとしている可能性があります。
NDR を無効にすることもできますが、正当なユーザーが誤ったアドレスを入力した場合、その電子メールが配信されなかったことをサーバーがユーザーに通知できなくなるため、重要なメッセージが失われる可能性があります。より優れた解決策を紹介します。
まず、第三者中継を許可しないようにします (先ほど言っておけばよかったですね)。次に、インテリジェント メッセージ フィルタ (IMF)、Exchange Server 2007 のコンテンツ フィルタ、リアルタイム ブロック リスト (RBL) などのウイルス対策フィルタを有効にします。このフィルタはエッジ トランスポートの役割またはハブ トランスポートの役割で構成できますが、一番初めのホップで構成するようにしてください。傾向として、90% を超えるメールがスパムであるため、迷惑メールが原因でサーバーの使用率が高くなり続ける状況を回避するために、この位置でフィルタを構成する必要があります。
最後に、環境内で外部からのメールを最初に受信する Exchange Server で受信者フィルタを有効にします。これにより、メッセージがネットワーク内に入ってくる前に、サーバーでそのメッセージを拒否できます。正当なアドレスの入力を誤った場合は NDR が配信されますが、この NDR は送信者のサーバーによって生成されます。
Q Exchange Server 2000 を実行している 1 台のサーバーと、Exchange Server 2003 を実行している 1 台のサーバーがあり、どちらも正常にメールをインターネットに送信していました。しかし、Exchange Server 2007 をインストールした後、どちらのサーバーのメールボックスからもメールを送信できなくなりました。
A これまでに 1 つしか Exchange Server を使用していなかった場合は、コネクタという概念にあまり詳しくないかもしれません。Exchange コネクタは、Exchange に電子メールの転送先を指示する論理的なルーティング構成オブジェクトです。Exchange Server 2007 を既存の組織に導入する場合、メールをルーティングするために、必ずルーティング グループ コネクタと SMTP コネクタを構成しなければなりません。
必要なルーティング グループ コネクタは 2 つです。1 つは、Exchange Server 2007 ルーティング グループから Exchange Server 2003 ルーティング グループへのコネクタ、もう 1 つはその逆方向のコネクタです。これらのコネクタはインストール プロセスの一環として構成できますが、構成していない場合や構成していない可能性がある場合は、Exchange 管理シェルを使用して確認を実行し、検出された問題をその場で解決できます。コネクタを構成しなければ、サーバー間でメールを送信することはできません。メッセージは "配信先に到達できないメッセージ" キューに格納されます。
インターネット メールのルーティングに必要なのは、1 つの SMTP コネクタのみです (Exchange Server 2007 では送信コネクタとしても知られています)。SMTP コネクタは Exchange Server 2000 と Exchange Server 2003 でも必要ですが、今まではなくても何とかなっていたのかもしれませんね。アドレス空間には、すべてのドメインで SMTP:* を指定する必要があります。また、メールの配信にスマート ホストと DNS のどちらを使用するかを指定できます。Exchange Server 2007 サーバーと以前のバージョンのサーバーのいずれかで送信インターネット メールを処理するか、両方のルーティング グループに SMTP コネクタを作成して、各サーバーでこれらのメールを処理することができます。エッジ トランスポート サーバーの役割がインストールされている場合は、Edgesync が実行する処理の一環として、SMTP コネクタを 1 つ作成できます。
SMTP 仮想サーバー上にスマート ホストが構成されている場合は、今がそれを削除する絶好のタイミングです。スマート ホストは仮想サーバー上には構成せず、SMTP コネクタ上のみに構成してください。仮想サーバー上に構成すると、ルーティング グループ コネクタで問題が発生します。
受信電子メールが MX レコードまたはファイアウォールの転送先 IP によって制御されていることも知っておく必要があります。Exchange 側で構成する設定はあまりありませんが、引き続き問題が発生する場合は、msexchangeteam.com/archive/2006/11/17/431555.aspx の資料を参照してください。
Q Exchange Server 2007 で同一のメッセージに関する複数のジャーナル レポートが生成されるのはなぜでしょうか。
A Exchange Server 2007 のトランスポート ジャーナリング エージェントでは、メッセージが分類された後に、それらのメッセージのジャーナルが作成されます。カテゴライザでは、さまざまな理由でメッセージが分割されます (つまり、メッセージ本文がコピーされ、異なるエンベロープの受信者が別々のコピーに埋め込まれます)。例を挙げて説明すると、ジャーナリングでは、メッセージが送信された時点の配布グループのメンバシップを報告できるようになったため、配布グループが入れ子になっている場合は、複数のレポートを受信する可能性があります。
このレポート機能の強化により、同一メッセージの複数のコピーを、それぞれに固有のレポートと共に受信する場合があります。あるメッセージに関するすべてのレポートを受信したかどうかを確実に知る方法はありませんが、アーカイブを行っている場合は、アーカイブ ベンダに問い合わせて、上記のような変更点を認識しているかどうかを確認したほうがよいでしょう。
Q Exchange Server 2007 では未解決のメッセージをホストに転送する機能がなくなってしまったのでしょうか。これからはどうすればよいですか。
A その機能は犬が食べてしまいました。
実は、この機能は複数の Exchange Server を運用している環境ではあまりうまく機能しませんでした。しかし、Exchange は既に別の方法でこの機能を実現しており、さらにその方法はより強力なものでした。具体的には、個々の SMTP ドメインを他のシステムと共有するという方法です。このため、未解決のメッセージを転送する機能は削除され、共有ドメインという概念が発展し、簡素化されました。Exchange Server 2007 では、[組織]、[ハブ トランスポート]、[承認済みドメイン] の順に選択し、ドメインの種類を [権限あり] から [内部の中継] に変更するだけで設定が完了します。環境によっては設定方法がやや複雑になるため、現在いくつかのドキュメントを更新しています。しかし、当面はこの設定が役立つはずです。
Q Exchange Server 2007 のインストール用にルート ドメインを準備しようとしています。Exchange Server 2003 の Exchange システム マネージャ (ESM) がインストールされているサーバーで Exchange Server 2007 セットアップを実行しようとしていますが、セットアップが失敗します。どこに問題があるのでしょうか。
A 簡単に言うと、Exchange Server 2000 または 2003 コンポーネントがインストールされているコンピュータで Exchange Server 2007 セットアップを実行することはできません。Exchange Server 2003 の ESM がインストールされている場合、Exchange Server 2007 セットアップによってこのコンポーネントが検出され、前提条件の確認が失敗します。このとき、"以前のバージョンの Exchange Server は、既にこのコンピュータにインストールされています。別のコンピュータから Exchange 2007 セットアップを実行するか、以前のバージョンの Exchange Server を削除してください。" というメッセージが表示されます。
この問題を最も簡単に解決する方法は、Exchange Server 2007 セットアップをルート ドメイン内の別のサーバーで実行してドメインを準備することです。この方法を実行できない場合は、Exchange Server 2003 コンポーネントをアンインストールしてから Exchange Server 2007 セットアップを実行する必要があります。
ドメインの準備は Exchange Server 2007 の 32 ビット版を使用して実行できるため、通常はルート ドメインにある任意の 32 ビット サーバーを使用できます。詳細については、technet.microsoft.com/library/bb232170.aspx を参照してください。
ところで、Exchange Server 2003 の ESM と Exchange Server 2007 の Exchange 管理コンソールを同一のコンピュータにインストールできない理由は、Exchange Server 2003 と Exchange Server 2007 の管理ツールを同一のコンピュータで共存させることができないためです。Exchange Server 2000 または Exchange Server 2003 コンポーネントがインストールされているコンピュータに Exchange Server 2007 をインストールしようとすると、セットアップはブロックされます。
最後に、Exchange Server 2007 管理ツールをインストールした後で、同一のコンピュータに Exchange Server 2003 ツールをインストールしないようにしてください。この方法で準備された構成はテストされていないため、サーバーを管理しようとしたときに予期しない動作が発生する場合があります。1 台のコンピュータで両方のサーバー バージョンを管理する必要がある場合は、リモート デスクトップを使用して一方のバージョンに接続するか、分離された環境でバーチャル マシンを使用して異なるバージョンの管理ツールをホストします。
Q いつになったら Windows Vista® ワークステーションで Exchange Server 2007 管理ツールを実行できるようになるのでしょうか。
A Exchange Server 2007 SP1 から、公式に Windows Vista で Exchange Server 2007 管理ツールがサポートされます。Exchange Server 2007 SP1 のリリースと同時に、Exchange Server 2007 SP1 の管理ツールが含まれたパッケージをダウンロードできます。
Q Windows Vista または Windows Server 2008 では Exchange Server 2003 ESM はサポートされるのでしょうか。このバージョンも実行できるようになりますか。
A いいえ。残念ながら、これは実現されません。Exchange Server 2007 SP1 より前のバージョンの Exchange Server で提供される管理ツールは、Windows Vista または Windows Server 2008 ではサポートされません。つまり、Windows Server 2008 のリリース後も、Exchange Server 2003 ESM を Windows Server 2008 にインストールできるようにはならないということです。Exchange Server 2003 サーバーの管理は、Windows Server 2003 または Windows XP ワークステーションから行うか、任意の OS からリモート デスクトップを使用して行う必要があります。
Q ドメイン内にいくつかの Exchange Server 2003 サーバーがあります。ドメイン コントローラを Windows Server 2008 ドメイン コントローラにアップグレードすることはできますか。
A はい。Windows Server 2008 ドメイン コントローラが存在するドメインでは、Exchange Server 2003 SP2 の実行がサポートされています。注意が必要なのは、Exchange Server は、Windows Server 2008 読み取り専用ドメイン コントローラ (RODC) および読み取り専用グローバル カタログ サーバー (ROGC) を使用できないということです。Windows Server 2008 RODC または ROGC を使用するよう Exchange Server に手動で指定する (ハードコードする) と、予期しない動作が発生する場合があります。
Nino Bilic は、Exchange Server のサポータビリティ プログラム マネージャです。寝る前に暇な時間があるときは、ネットワーク モニタの大量のトレース結果を読み、サーバー間通信のすばらしさを見出しています。
Scott Landry は、Exchange Server のサポート エスカレーション エンジニアです。彼の外出時の必需品は、タオル、ガイドブックのコピー、および頼りになる Windows Mobile が搭載された携帯電話です。
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.