パート II Messaging Server の配備

この部には、次の章があります。

• 第 9 章「Messaging Server ソフトウェアの紹介」

• 第 10 章「Messaging Server サイズ決定戦略の計画」

• 第 11 章「Messaging Server アーキテクチャーの開発」

• 第 12 章「Messaging Server トポロジの設計」

• 第 13 章「Messaging Server セキュリティーの計画」

• 第 14 章「Messaging Server スパム防止およびウイルス対策戦略の計画」

• 第 15 章「Messaging Server インストール前の考慮事項と手順について」

第 9 章 Messaging Server ソフトウェアの紹介

Sun Java System Messaging Server は、企業とサービスプロバイダの両方で要求される大容量で信頼性の高いメッセージング処理のために設計された、強力なインターネットメッセージングサーバーです。サーバーはモジュール化された、個別に構成可能な複数のコンポーネントから成り立っています。これらのコンポーネントは、さまざまな電子メールプロトコルをサポートしています。

Messaging Server は、ユーザー、グループ、およびドメインについての情報を格納するために一元化された LDAP データベースを使用します。サーバー設定についてのいくつかの情報は LDAP データベースに格納されます。また、ローカル設定ファイルに格納される情報もあります。

Messaging Server 製品群には、ユーザーのプロビジョニングやサーバーの構成をサポートするツールが含まれています。

この章には、次の節があります。

• 「メッセージングシステムとは」

• 「Messaging Server がサポートする標準と機能」

• 「Messaging Server のソフトウェアアーキテクチャー」

メッセージングシステムとは

すぐれた電子メールシステムアーキテクチャーでは、埋め込まれたサウンド、画像、ビデオファイル、HTML 形式とともに電子メールが迅速に配信され、将来のアップグレードへの対応とスケーラビリティを提供します。単純化すると、Messaging Server アーキテクチャーは次の機能を備える必要があります。

• 外部サイトからのメールを受信する

• これらのメッセージが配信されるユーザーメールボックスを判断し、そこにルーティングする

• 内部ホストからのメールを受信する

• これらのメッセージの配信先となるシステムを判断し、そこにルーティングする

電子メールシステムアーキテクチャーの中心はメッセージングサーバー自体で、これはメッセージの送信と配信に使用されるコンポーネントの集合体です。Messaging Server で提供されるコンポーネントとは別に、電子メールシステムでは LDAP サーバーと DNS サーバーも必要となります。DNS サーバーは、電子メールシステムを配備する前に配置しておく必要があります。

効率性とスケーラビリティ以外にも、いくつかの要素が Messaging Server アーキテクチャーに影響を与えます。これらの要素を次に示します。

• 負荷分散

• ファイアウォール

• 高可用性

これらのトピックの詳細については、第 11 章「Messaging Server アーキテクチャーの開発」を参照してください。

Messaging Server がサポートする標準と機能

この節では、Messaging Server がサポートする標準について説明するほか、Messaging Server がサポートするその他の機能についても説明します。

標準プロトコルのサポート

Messaging Server は、電子メッセージングに関連するほとんどの国内規格、国際規格、および業界規格をサポートしています。完全なリストは、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の付録 A「Supported Standards」を参照してください。

ホストされているドメインのサポート

Messaging Server は、ISP にアウトソースされた電子メールドメインのようなホストされているドメインを完全にサポートしています。つまり、ISP は組織の電子メールサービスをリモートで操作および管理することにより組織をホスティングする電子メールドメインを提供します。ホストしているドメインは、ほかのホストしているドメインと同じ Messaging Server ホストを共有することができます。初期の LDAP ベースの電子メールシステムでは、1 つのドメインが 1 つまたは複数の電子メールサーバーホストによってサポートされていました。Messaging Server では、複数のドメインを単一のサーバーでホストできます。ホストされている各ドメインには、そのドメインのユーザーとグループのコンテナを指し、さまざまなドメイン固有のデフォルト設定を提供する LDAP エントリがあります。

ドメインを定義する場合、そのドメインに対応するドメインエントリがディレクトリ内に存在する必要があります。つまり、そのドメインに対する LDAP エントリを作成する必要があります。mailAlternateAddress や mailEquivalentAddress などの属性は、ディレクトリ内のドメインエントリの存在に依存します。これは、バニティドメインの場合とは対照的です。バニティドメインは、特定のサーバーやホストされたドメインに関連付けられるのではなく、特定のユーザーに関連付けられたドメイン名です。バニティドメインの場合、そのドメイン名に対する LDAP エントリは存在しません。

バニティドメインを使用すると処理時のオーバーヘッドが増大します。したがって、その使用はお勧めできません。

ユーザーのプロビジョニングのサポート

Messaging Server は、ユーザー、グループ、およびドメインについての情報を格納するために一元化された LDAP データベースを使用します。現在、Messaging Server は Sun Java System LDAP スキーマバージョン 1 (スキーマ 1) と Sun Java System LDAP スキーマバージョン 2 (スキーマ 2) の 2 つのスキーマオプションをサポートしています。プロビジョニングオプションは、選択されたスキーマにより異なります。詳細については、第 15 章「Messaging Server インストール前の考慮事項と手順について」を参照してください。

スキーマ 2 の Messaging Server プロビジョニングは、Delegated Administrator を使って行います。これについては、『Sun Java System Communications Services 6 2005Q4 Delegated Administrator 管理ガイド』を参照してください。

スキーマ 1 は、メッセージング用 iPlanet Delegated Administrator 製品によってサポートされています。この製品には、組織内のユーザー、グループ、およびドメインを管理するために、グラフィカルユーザーインタフェースとコマンド行ユーティリティーが用意されています。スキーマ 1 におけるユーザー、グループ、およびドメイン管理については、以前のリリースのソフトウェアに関する次のマニュアルを参照することもできます。

• 『iPlanet Messaging Server 5.2 Provisioning Guide』 - LDAP を使ってドメイン、ユーザー、グループ、または管理者のエントリを作成する方法を説明しています。

• 『iPlanet Messaging and Collaboration Schema Reference』 - Communications Services のスキーマ 1 について説明しています。

• 『iPlanet Messaging Server 5.2 Reference Manual』 - ユーザー、グループ、およびドメインを管理するための iPlanet Delegated Administrator コマンド行ユーティリティーについて説明しています。

• iPlanet Delegated Administrator オンラインヘルプ

Access Manager コンソールは、Messaging Server と Calendar Server の LDAP ユーザーエントリに対し、Access Manager サービスによる最小限のプロビジョニング機能を提供します。インタフェースには入力を確認する機能がないため、電子メールを受け取ることができないユーザーエントリや動作しないユーザーエントリが、エラーが報告されることなく作成されてしまいます。そのため、このインタフェースはデモの目的でだけ使用します。

『Sun Java System Communications Services 6 2005Q4 Delegated Administrator 管理ガイド』で説明している Delegated Administrator は、Communications Services ユーザーをプロビジョニングするための推奨メカニズムです。

統一されたメッセージングのサポート

Messaging Server は完全な、統一されたメッセージングソリューションの基盤となります。統一されたメッセージングとは、電子メール、ボイスメール、FAX、ビデオ、およびそのほかの通信形態に関して単一のメッセージストアを使用するという概念です。

Web メールのサポート

Messaging Server は現在、次の 2 つのクライアント向けユーザーインタフェース (UI) をサポートしています。

• Messenger Express

• Communications Express

今後、Messenger Express ユーザーインタフェースに新機能が追加されることはありません。Messaging Server は非推奨となり、代わって Communications Express が推奨のユーザーインタフェースとなりました。Sun Microsystems, Inc. は後日、Messenger Express の生産中止スケジュールを発表する予定です。

詳細については、Communications Express のマニュアルを参照してください。

http://docs.sun.com/app/docs/coll/1312.1

Messaging Server のセキュリティとアクセス制御

Messaging Server には、次のセキュリティとアクセス制御の機能があります。

• POP、IMAP、HTTP、または SMTP へのパスワードによるログインおよび証明書に基づくログインのサポート

• 標準セキュリティプロトコルのサポート: TLS (Transport Layer Security)、SSL (Secure Sockets Layer)、および SASL (Simple Authentication and Security Layer)

• Delegated Administrator

• POP、IMAP、SMTP および HTTP へのクライアント IP アドレスアクセスのフィルタ

• システム全体、ユーザーごと、およびサーバー側の Sieve 規則による、大量な迷惑メールのフィルタリング

Messaging Server の管理ユーザーインタフェース

Messaging Server はモジュール化された、個別に構成可能な複数のコンポーネントから成ります。これらのコンポーネントは、電子メールの転送とアクセスプロトコルをサポートしています。

メッセージ転送エージェント (MTA) を設定するために、Messaging Server には、サーバー上にローカルに格納されたコマンド行ユーティリティーと設定ファイルの完全なセットが用意されています。また、メッセージストアおよびメッセージアクセスサービスを設定するために、コンソールグラフィカルユーザーインタフェースとコマンド行ユーティリティーの完全なセットが用意されています。

詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』を参照してください。

Messaging Server のソフトウェアアーキテクチャー

図 9–1 は、スタンドアロンの Messaging Server を簡略化して示しています。この特別な配備は、スケーラビリティが低いため、大規模配備にはお勧めできませんが、Messaging Server の個々のコンポーネントを示しています。

図 9–1 スタンドアロンの Messaging Server の簡略化したコンポーネント表示

この図は、次の Messaging Server ソフトウェアコンポーネントを示しています。

• メッセージ転送エージェント (MTA): SMTP プロトコルを使用して、メールメッセージの受信、ルーティング、転送、および配信を行います。MTA は、ローカルのメールボックスか別の MTA にメッセージを配信します。

• メッセージストア: メールクライアントのメッセージの格納、取得、および操作を行う一連のコンポーネントで構成されます。メールは POP クライアント、IMAP クライアント、または HTTP クライアントにより取得されます。POP クライアントは、メッセージをクライアントマシンにダウンロードして、読み取りと保管を行います。IMAP クライアントと HTTP クライアントは、サーバー上のメッセージの読み取りと操作を行います。

• LDAP ディレクトリ: Messaging Server のメールディレクトリ情報の保管、取得、および配信を行います。これには、ユーザーのルーティング情報、配信リスト、設定データ、および電子メールの配信とアクセスのサポートに必要なその他の情報などがあります。また、MTA またはメッセージストアがユーザー認証時に必要とするパスワードなどの情報も、LDAP ディレクトリ内に格納されます。

  メッセージを格納するだけでなく、メッセージストアはディレクトリサーバーを使用して、メールクライアントがメールにアクセスする場合のユーザーのログイン名とパスワードの検証も行います。ディレクトリには、割り当て制限、デフォルトのメッセージストアタイプなどの情報も格納されます。

• DNS サーバー: ドメイン名を IP アドレスに変換します。このコンポーネントは Messaging Server をインストールする前に必要となります。

簡略化した Messaging Server システムを通したメッセージパス

インターネットまたはローカルクライアントからの受信メッセージは、Simple Mail Transport Protocol (SMTP) を通じて MTA によって受信されます。内部アドレスの場合、すなわち Messaging Server ドメイン内の場合は、MTA はメッセージをメッセージストアに配信します。メッセージが外部宛て、すなわち Messaging Server の制御外のドメイン宛ての場合、MTA はメッセージをインターネット上の別の MTA にリレーします。

UNIX システムの場合に限り、/var/mail ファイルシステムにメールを配信することも可能ですが、ローカルメッセージは通常、より最適化された Messaging Server メッセージストアに配信されます。次に、IMAP4、POP3 、または HTTP メールクライアントプログラムがメッセージを取得します。

メールクライアントからの送信メッセージは MTA に直接送られ、そこでインターネット上の適切なサーバーに送信されます。アドレスがローカルの場合は、MTA はメッセージをメッセージストアに送信します。

新しいユーザーとグループは、ディレクトリにユーザーとグループのエントリを追加することで作成されます。Communications Services Delegated Administrator ユーティリティーを使用するか、LDAP を使用してディレクトリを変更することで、エントリを作成または変更することができます。

Messaging Server コンポーネントは、管理サーバーコンソールを使って管理できます。さらに、Messaging Server には一連のコマンド行インタフェースと設定ファイルも用意されています。より一般的な管理タスクとしては、メールシステムへのユーザーやグループの追加、変更、削除や、MTA、ディレクトリサーバー、およびメッセージングストアの操作の設定があります。

メッセージ転送エージェント (MTA)

MTA は、Messaging Server に宛てられたインターネットメールメッセージのルーティング、転送、および配信を行います。メールは、「チャネル」と呼ばれるインタフェース内を通過します。各チャネルは、1 つまたは 1 組のエージェントプログラムと一連の設定情報とで構成されます。エージェントプログラムには、チャネルに入ってきたメールを処理する「スレーブプログラム」と、チャネルを出ていくメールを処理する「マスタープログラム」があります。任意のチャネルに関連付けられた 1 つ以上のインタフェースに送られるメッセージを格納するためのメッセージキューがあります。Messaging Server には、次のような数多くのチャネルがデフォルトで用意されています。

• SMTP チャネル: TCP/IP ベースのメッセージ配信と受信を有効にします。マスターチャネルとスレーブチャネルが用意されます。

• LMTP チャネル: 2 層構成における MTA から メッセージストアへのメッセージの直接ルーティングを有効にします。これらのチャネルは、SMTP ではなく LMTP を使用して別のシステム上のメッセージストアと通信を行います。マスターチャネルとスレーブチャネルが用意されます。

• パイプチャネル: 代替メッセージ配信プログラムで使用します。メッセージをユーザーの受信箱に直接送るのではなく、メールソーターのようなプログラムへの配信を行います。マスターチャネルが用意されます。

• ローカルチャネル:メールを /var/mail に配信します。古い UNIX メールクライアントとの互換性を提供します。マスターチャネルが用意されます。

• 再処理チャネル: 再送信されたメッセージの処理に役立ちます。マスターチャネルが用意されます。

• 再組立チャネル: 不完全なメッセージを再度組み立て、MIME の Message/Partial Content-type をサポートする元の完全なメッセージにします。マスターチャネルが用意されます。

• 変換チャネル: メッセージを本文ごとに変換します。アドレスの再書き込みまたはメッセージの再フォーマットに役立ちます。マスターチャネルが用意されます。

• メッセージストアチャネル: メッセージストアへのローカル配信を行います。

図 9–2 は、このプロセスを示したものです。チャネルを個別に設定し、アドレスに基づいてメールを特定のチャネルに送ることもできます。

図 9–2 チャネルアーキテクチャー

チャネルプログラムは、次の 2 つの機能の 1 つを実行します。

• SMTP スレーブプログラムは、メッセージをメッセージキューに入れて MTA による次の処理に備えるか、システムに受け入れることのできないメッセージを拒否し、他のインタフェースからのメッセージを受け入れます。

• マスタープログラムは、キュー領域からのメッセージを処理し、それを同じシステムのキューに入れて、別のチャネルによる処理に備えます。または、他のインタフェースに送信し、送信後にキューから削除します。あるいは、そのメッセージをメッセージストアのようなシステム上の最終送信先に配信します。

チャネルの設定は、imta.cnf 設定テキストファイルを使用して行います。チャネル設定を通じて、さまざまな「チャネルキーワード」を設定してメッセージの処理方法を制御できます。チャネルキーワードは、パフォーマンスの調整とシステムのレポーティング面に影響を与えます。たとえば、複数のチャネルを定義してトラフィックを送信先別に分類し、メッセージサイズを制限してトラフィックを制限し、業務のニーズに応じて配信状態通知規則を定義します。診断属性もチャネル単位で設定可能です。かなりの数の設定パラメータが、チャネルベースで設定可能です。

MTA の概念の詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 8 章「MTA の概念」を参照してください。

LDAP 直接検索

MTA は、情報の検索を LDAP サーバーに対して直接行います。直接検索により、MTA と LDAP サーバーとの関係がスケーラブルで高速かつ設定可能になります。LDAP クエリの結果は設定可能なサイズと時間でプロセスにキャッシュされるため、パフォーマンスの調整が可能です。詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』を参照してください。

書き換え規則

メールは、「ドメイン書き換え規則」(略して「書き換え規則」) が適用された送信先アドレスの実行結果に基づいて、チャネルにルーティングされます。書き換え規則は、アドレスを真のドメインアドレスに変換し、それに対応するチャネルを決定するために使用されます。これらの規則は、「トランスポート層」と「メッセージヘッダー」の両方に表示されるアドレスを書き換えるために使用されます。トランスポート層は、メッセージのエンベロープです。ルーティング情報はユーザーには見えない形で含まれていますが、実際の情報はメッセージを適切な受信者に配信するのに使用されます。

書き換え規則とチャネルのテーブルは、協力してそれぞれのアドレスの処置を決定します。書き換えプロセスの結果により、アドレスとルーティングシステム、すなわちメッセージが送信またはキューイングされるシステム (チャネル) が書き換えられます。ネットワークのトポロジ次第で、ルーティングシステムはメッセージが送信先までにたどるパスの最初のステップである場合もあれば、最終の送信先システムである場合もあります。

書き換えプロセスが終了すると、imta.cnf ファイルのチャネル部分に対してルーティングシステムの検索が行われます。それぞれのチャネルには、チャネルに関連付けられた 1 つ以上のホスト名があります。ルーティングシステム名がそれぞれのホスト名と比較されて、メッセージがどのチャネルのキューに入れられるかが決定されます。次に簡単な書き換え規則を示します。

example.com     $U%example.com@tcp_siroe-daemon

この規則は、ドメイン example.com のアドレスだけを検索します。一致したアドレスは、次に示すテンプレート$U%$D を使用して書き換えられます。

$U

アドレスのユーザーの部分またはアドレスの左側 (@ の前) を示します

%

@ 符号を示します

$D

アドレスのドメインの部分またはアドレスの右側 (@ の後ろ) を示します

このように、wallaby@thor.example.com の形式のメッセージが wallaby@example.com に書き換えられ、tcp_siroe-daemon をチャネルホスト名に持つチャネルに送信されます。

書き換え規則は、マッピングテーブル、LDAP ディレクトリ検索、およびデータベース参照に基づいて、高度な置換を行うこともできます。暗号のようなわかりにくいものになる場合もありますが、書き換え規則が低レベルで動作し、処理サイクルへの直接のオーバーヘッドがほとんどない点が便利です。書き換え規則の詳細と書き換えプロセスで利用できる機能については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 11 章「書き換えルールの設定」を参照してください。

ジョブコントローラ

マスターチャネルプログラムは、ジョブコントローラの制御下で実行されます。ジョブコントローラは、メッセージキューを制御し、実際のメッセージ配信を行うチャネルプログラムを呼び出すプログラムです。ジョブコントローラはマルチスレッドプロセスであり、Messaging Server システムに常駐している数少ないプロセスの 1 つです。チャネル処理ジョブ自体は、ジョブコントローラにより作成されますが、一時的なジョブで、実行する作業がない場合は存在しなくなります。

ジョブコントローラの設定により、チャネル処理プログラムのインスタンスが常に少なくとも 1 つ存在するかどうかが決まります。多くの場合は、すぐに実行する作業がなくてもサービスプログラムのインスタンスが少なくとも 1 つは常に存在するように設定されます。それ以外の場合は、現在行うべき作業がなくなってから一定期間の間インスタンスが存在することになります。

外部メッセージを受け入れたスレーブチャネルは、メッセージをキューイングすることにより、新しいメッセージファイルが作成されたことをジョブコントローラに通知します。ジョブコントローラは、この情報を内部データ構造に入力し、必要に応じてそのキュー内のメッセージを処理するマスターチャネルジョブを作成します。ジョブコントローラで、既存のチャネルジョブが新しくキューイングされたメッセージファイルを処理できるように設定されている場合は、このジョブを作成する必要はありません。マスターチャネルジョブは、ジョブが開始されると、ジョブコントローラからメッセージ割り当てを取得します。メッセージの処理を終了すると、マスターチャネルはその処理のステータスに応じてジョブコントローラを更新します。そのステータスは、メッセージが正常にキューから削除されたか、メッセージの再配信スケジュールが組まれたかのいずれかになります。

ジョブコントローラは、メッセージの優先度と失敗した配信に関する情報を維持し、チャネルジョブに優先的なスケジュールを許可します。ジョブコントローラは、各ジョブの状態の追跡も行います。ジョブの状態は、アイドル、アイドルの時間、ジョブがビジーであるかどうかです。状態の追跡により、ジョブコントローラはチャネルジョブの最適なプールを維持できます。

現時点で存在しているスレーブチャネルは、SMTP スレーブと LMTP スレーブの 2 つだけです。次に、これらのプログラムを制御するディスパッチャーについて説明します。

ディスパッチャー

ディスパッチャーは、Messaging Server システムに常駐しているもう 1 つのプロセスです。これはマルチスレッドのトラフィックディスパッチャーであり、着信した SMTP 接続または LMTP 接続を、プロトコル固有の処理が行えるように SMTP サーバースレッドまたは LMTP サーバースレッドのプールへと振り分けます。SMTP サーバープログラムと LMTP サーバープログラムは、ディスパッチャーによって制御されるワークスレッドのプールを提供します。メッセージ処理 (メッセージの拒否または送信先チャネルへのメッセージのキューイング) が完了すると、ワークスレッドは、ディスパッチャーから別の作業を受け入れられる状態になります。

ディスパッチャーは IP アドレスに基づいて着信トラフィックをブロックできるため、サービス拒否攻撃を回避することができます。また、ディスパッチャーは、負荷と設定に基づく SMTP サーバープロセスまたは LMTP サーバープロセスの作成およびシャットダウンも行います。このように、SMTP または LMTP のスレーブチャネルプログラムは、ジョブコントローラの制御下ではなく、ディスパッチャーの制御下にあります。

Local Mail Transfer Protocol (LMTP)

Messaging Server 6.0 リリースでは、複数階層配備におけるメッセージストアに配信を行う LMTP 設定が可能になりました。インバウンドリレーとバックエンドメッセージストアが使用されるこのような環境では、アドレス拡張、自動返信や転送などの配信方法、およびメーリングリストの拡張などに関してリレーが重要な役割を果たします。

バックエンドストアへの配信はこれまで SMTP 上で行われてきました。SMTP では、バックエンドシステムで LDAP ディレクトリの受取人アドレスを再度調べる必要があるため、MTA の全機能が使用されます。速度と効率性を向上するために、MTA では SMTP ではなく LMTP を使用してバックエンドストアにメッセージを配信できます。詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 15 章「LMTP 配信」を参照してください。

LMTP は、複数階層配備で使用されるように設計されています。LMTP を単一システム配備で使用することはできません。Messaging Server に実装されている LMTP サービスは、ほかの LMTP サーバーまたは LMTP クライアントと連携して動作するように設計されていません。

メッセージストア

メッセージストアは、インターネットメールメッセージの配信、取得、および操作の ための専用のデータストアです。メッセージストアは IMAP4 および POP3 クライアントアクセスサーバーとともに動作し、メッセージへの柔軟で容易なアクセスを提供します。また、メッセージストアは HTTP サーバー (mshttpd) 経由でも動作します。これにより、Web ブラウザ内の Communications Express に対してメッセージング機能が提供されます。詳細については、この節のほかに、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』を参照してください。

メッセージストアは、一連のフォルダまたはユーザーメールボックスとして構成されます。フォルダまたはメールボックスは、メッセージのコンテナです。それぞれのユーザーには、新しく受信したメールが入る INBOX があります。それぞれの IMAP ユーザーまたは Web メールユーザーには、メールを格納できる 1 つ以上のフォルダがあります。フォルダには、他のフォルダを階層構造で含めることができます。個別のユーザーが所有するメールボックスは非公開フォルダです。非公開フォルダは、所有者の判断で、同じメッセージストア内のほかのユーザーと共有できます。Messaging Server は、IMAP プロトコルによる複数ストア間でのフォルダ共有をサポートします。

メッセージストアには、ユーザーファイルとシステムファイルの 2 つの一般領域があります。ユーザー領域では、それぞれのユーザーの INBOX の位置が 2 階層ハッシングアルゴリズムを使用して決定されます。それぞれのユーザーのメールボックスまたはフォルダは、その親フォルダ内の別のディレクトリとして表されます。各メッセージは 1 つのファイルとして格納されます。フォルダ内に大量のメッセージがある場合は、システムによりフォルダのハッシュディレクトリが作成されます。ハッシュディレクトリを使用することで、フォルダに大量のメッセージがある場合にファイルシステムが抱える負担が軽減されます。メッセージストアでは、メッセージ自体のほかに、メッセージヘッダー情報の索引とキャッシュ、およびその他の頻繁に使用されるデータが維持されるため、クライアントはメールボックスの情報を迅速に取得し、個別のメッセージファイルにアクセスすることなく一般的な検索を実行できます。

メッセージストアには、多くのユーザーファイル用メッセージストアパーティションを含めることができます。メッセージストアパーティションは、ファイルシステムボリュームに格納されます。ファイルシステムがいっぱいになると、追加のファイルシステムボリュームを作成し、それらのファイルシステムボリューム上に新しいユーザーを格納するためのメッセージストアパーティションを作成できます。

パーティションがいっぱいになると、そのパーティション上のユーザーは、新たなメッセージを格納できなくなります。この問題を解決するには、次の方法があります。

• ユーザーのメールボックスのサイズを縮小する

• ボリューム管理ソフトウェアを使用している場合、別のディスクを追加する

• 別のパーティションを作成し、その新しいパーティションにメールボックスを移動する

詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 18 章「メッセージストアを管理する」を参照してください。

メッセージストアは、パーティションごとにメッセージそれぞれのコピーを 1 つずつだけ維持します。これは、シングルコピーメッセージストアとも呼ばれます。メッセージストアが複数のユーザー、グループ、または配信リストに宛てられたメッセージを受信した場合、それぞれのユーザーの INBOX にそのメッセージへの参照を追加します。メッセージストアでは、メッセージのコピーをそれぞれのユーザーの INBOX に保存するのではなく、同じデータを重複して保存しないようにしています。既読、返信済み、削除などの個別メッセージステータスのフラグは、それぞれのユーザーのフォルダごとに維持されます。

システム領域には、メッセージストア全体の情報が特定のデータベース形式で格納されており、高速なアクセスを実現しています。システム領域内の情報は、ユーザー領域から再構築できます。Messaging Server にはデータベーススナップショット機能が含まれています。必要な場合には、データベースを既知の状態に迅速に回復できます。Messaging Server には高速回復機能もあり、データベースが破損した場合には、データベース再構築のために長い時間待つことなく、メッセージストアをシャットダウンして、すぐに元の状態に戻すことができます。

メッセージストアはユーザー単位の割り当てをサポートします。割り当ての拡張は有効にすることも無効にすることもできます。ユーザー割り当ては、バイト数またはメッセージ数を使用して設定できます。しきい値を設定して、割り当てがしきい値に達した場合には、ユーザーに警告を出すこともできます。ユーザーが割り当てを超過した場合は、猶予期間中の新規メッセージは保留され、再試行されます。猶予期間の後で、割り当てを超過したユーザーに送信されたメッセージは、未送信通知と共に送信者に返されます。

割り当てを使用する特別なアプリケーションで、ユーザーの割り当てステータスに関係なくメッセージが配信されなければならない場合には、保証メッセージ配信チャネルがあります。このチャネルは、割り当てステータスに関係なくすべてのメッセージを配信するのに使用できます。割り当て使用率のレポートと割り当て警告の送信を行うユーティリティーも用意されています。

Messaging Server とディレクトリサービス

Messaging Server は、Sun Java System Directory Server にバンドルされています。Directory Server は、LDAP (Lightweight Directory Access Protocol) ディレクトリサービスです。Directory Server は、Messaging Server の運用に不可欠な情報のための中央リポジトリを提供します。この情報には、ユーザープロファイル、配信リスト、およびその他のシステムリソースなどが含まれます。

ディレクトリ情報ツリー

ディレクトリは、ディレクトリ情報ツリー (DIT) として知られるツリー形式でデータを格納します。DIT は、ツリーの最上部に 1 つの主要ブランチがあり、その下にブランチおよびサブブランチがある階層構造です。DIT は、組織のニーズに合わせた配備の設計を可能にする柔軟性を備えています。たとえば、実際の業務組織構造に従った DIT の配置を選択することも、業務の地理的なレイアウトに従って選択することもできます。また、使用する DNS レイヤーに 1 対 1 でマッピングした DIT を設計することもできます。実稼働後の DIT の変更は大変な作業となるため、DIT の設計は慎重に行なってください。

DIT は、幅広い管理シナリオに適応する柔軟性も備えています。DIT は、集中型でも分散型でも管理できます。集中型の管理では、1 つの権限で DIT 全体を管理します。集中型管理の場合は、DIT 全体を 1 つのメールサーバー上に配置して使用します。分散型管理では、複数の権限で DIT を管理します。通常は、DIT がいくつかの部分、サブツリー、または異なるメールサーバーに分割された場合に分散型管理を用います。

DIT が大規模な場合、またはメールサーバーが地理的に分散されている場合は、DIT の一部の管理を委託することも検討します。通常は、DIT のそれぞれのサブツリーを管理する権限を割り当てます。Messaging Server では、1 つの権限で複数のサブツリーの管理が可能です。ただしセキュリティ上の理由で、権限は、その権限が所有する DIT のサブツリーの変更だけが可能となっています。

Access Manager が使用されない場合に Messaging Server が使用するデフォルトのスキーマは、Access Manager が使用するスキーマとは異なります。Messaging Server は、Sun Java System LDAP スキーマ 1 および 2 をサポートしており、スキーマの切り替えと移行も可能です。

ディレクトリのレプリケーション

Directory Server はレプリケーションをサポートしており、冗長性と効率性を実現するさまざまな設定が可能です。1 つのホストから別のホストへの DIT の全部または一部をレプリケーションすることで、次の設定機能が利用できます。

• ディレクトリ情報が 1 つのサーバー上にだけあるのではなく、複数のサーバーにレプリケートされるため、ディレクトリ情報へのアクセスがより容易になります。

• ディレクトリ情報はローカルディレクトリサーバーにキャッシュされ、リモートディレクトリサーバーから情報にアクセスする手間を省いています。ディレクトリ情報のキャッシュにより、特に中央ディレクトリへのネットワーク帯域幅が限られている配備では、パフォーマンスが向上します。

• 実際の設定次第で、複数のディレクトリサーバーは単独の集中型サーバーよりも、メールクライアントの要求をより高速に処理できます。

ディレクトリのレプリケーション、ディレクトリパフォーマンスの調整、DIT 構造と設計の詳細については、Sun Java System Directory Server のマニュアルを参照してください。

http://docs.sun.com/app/docs/coll/1316.1

メッセージングユーザーのプロビジョニング

Messaging Server ユーザーに対するスキーマとプロビジョニングのオプションについては、第 8 章「スキーマとプロビジョニングのオプションについて」を参照してください。

第 10 章 Messaging Server サイズ決定戦略の計画

配備を計画する場合には、Messaging Server の設定方法を検討して、パフォーマンス、スケーラビリティー、および信頼性を最適化する必要があります。

サイズ決定はそのための重要な要素の 1 つです。サイズ決定のプロセスを実行することで、Messaging Server ユーザーへの作業負荷の見積もりを踏まえた、希望するレベルのサービスまたは応答時間を実現するために必要となるハードウェアとソフトウェアを確認できます。サイズ決定は反復的な作業です。

この章は、Messaging Server 配備のサイズ決定の基礎について説明し、正しいサイズ決定データを得て配備上の判断ができるようにすることを目的としています。また、Messaging Server のサイズ決定プロセスの背景と理論的根拠についても説明します。

この章には、次の節があります。

• 「Messaging Server サイズ決定データの収集」

• 「Messenger Express 負荷シミュレータの使用」

• 「Messaging Server システムパフォーマンスの評価」

• 「Messaging Server アーキテクチャー戦略の構築」

配備にはそれぞれに固有の特徴があるため、この章では特定のサイトに関するサイズ決定情報の詳細な説明はしていません。代わりにここでは、サイズ決定計画を構築する場合には何を考慮しなければならないのかを説明します。配備のハードウェアとソフトウェアのニーズを決定する場合には、ご購入先のテクニカルサポート担当者とともに作業を行なってください。

Messaging Server サイズ決定データの収集

この節の説明を読んで、Messaging Server 配備のサイズ決定に必要なデータを確認してください。この節には、次の項目があります。

• 「メッセージングのピークボリュームの判断」

• 「メッセージングの使用率プロファイルの作成」

• 「メッセージングユーザーベースの定義」

メッセージングのピークボリュームの判断

「ピークボリューム」は、1 日の特定の時間帯でメッセージングシステムにトランザクションがもっとも集中したときのトランザクション数です。このボリュームは、サイト間やユーザークラスの違いにより大きく異なります。たとえば、ある中規模企業のマネージャークラスでは、朝の 9 時から 10 時の間、昼の 12 時から 1 時の間、夕方の 5 時から 6 時の間にピークボリュームが発生します。

ピークボリュームの分析には、次の 3 つの基本処理が含まれます。

1. ピークがいつ発生し、どのくらい継続するかを判断します

2. ピークボリューム負荷を前提として配備のサイズを決定します

   パターンの分析が終了すれば、システムの負荷を処理しやすくし、ユーザーの求めるサービスを提供するための選択を行えます。

3. ユーザーが決定したピークボリュームを Messaging Server 配備がサポートできることを確認します

メッセージングの使用率プロファイルの作成

正確なサイズ決定には、負荷の測定が不可欠です。「使用率プロファイル」により、Messaging Server ホスト上のプログラムとプロセスが実行する要素が決定されます。

この節では、使用率プロファイルを作成して、配備で発生する負荷の量を測定する方法について説明します。

使用率プロファイルを作成するには、次の質問に答えてください。

1. システムのユーザー数は何人ですか。

   システムのユーザー数を数える時には、メールアカウントを持ちメールシステムにログインできるユーザーだけでなく、メールアカウントを持っているが、現在システムにはログインしていないユーザーも含めます。特に、次に示しているアクティブなユーザーとアクティブでないユーザーとの相違点に注意してください。

   ユーザー	説明
   アクティブなユーザー	POP、IMAP、または HTTP のようなメールアクセスプロトコルを使用してメールシステムにログインしているユーザー。アクセスプロトコルの種類により、アクティブなユーザーはメールサーバーに接続していたり、接続していなかったりします。 たとえば、POP ユーザーはメールアカウントを開きますが、メールクライアントからメールサーバーに対して確立される POP 接続は短時間で、断続的です。  ここで説明しているアクティブなユーザーは、mailuserstatus やinetuserstatus のような active ステータスを持ったメール属性ではありません。メール属性の詳細については、『Sun Java System Communications Services Schema Reference 』を参照してください。
   アクティブでないユーザー	メールアカウントを持っているが、現在はメールシステムを使用していないユーザー。

   ユーザー数が 300 以下のきわめて小規模な配備の場合は、サイズ決定戦略の計画でこのプロセスを実行する必要はありません。クライアントサービス担当者と作業を行い、個別のニーズについて判断します。

2. POP、IMAP、および Messenger Express クライアントがサービスにアクセスするピークボリューム時に、システムへの接続数はどのくらいになりますか。

   特に、サポートするそれぞれのクライアントアクセスサービスの並行接続、アイドル接続、ビジー接続の数に注意します。

   接続	説明
   並行接続	ある時間にメールシステム上で確立される、固有の TCP 接続またはセッション (HTTP、POP、または IMAP) の数。  アクティブなユーザーは複数の並行 IMAP セッションを行うことができます。一方、POP クライアントまたは Messenger Express クライアントを使用するユーザーは、クライアントごとに 1 つの接続しか確立できません。さらに、POP 接続と Messenger Express 接続は、サーバーに接続してデータを取得し、サーバーへの接続を切断して、データの表示、ユーザー入力の受け入れを行い、そしてメールサーバーへの再接続を行うため、POP および Messenger Express クライアントアクセスサービスのアクティブなユーザーは、ある時点においてはアクティブな接続を行わずにサービスにアクセスすることも可能です。
   アイドル接続	確立された IMAP 接続で、時々送信される check または noop コマンドを除き、メールクライアントと Messaging Server との間で情報送信を行わないもの。
   ビジー接続	進行中の接続。ビジー接続の例としては、メールクライアントが送信したばかりのコマンドを処理中、つまり、メールクライアントに応答を送り返している状態のメールサーバーがあります。

   配備における「並行接続」の数は、次のいずれかの方法で決定します。

   1. UNIX プラットフォームで netstat コマンドを使用して、確立された TCP 接続数をカウントします。

   2. Messenger Express または IMAP のユーザーの、最後のログイン時刻とログアウト時刻を取得します。詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』を参照してください。

3. 大規模な配備を行う場合には、ユーザーをどのように組織化しますか。

   次の選択肢が考えられますが、これに限られません。

   • アクティブなユーザーとアクティブでないユーザーをそれぞれのマシンから集めて、アクティブユーザーを集めたマシンと非アクティブユーザーを集めたマシンとに分けます。

     アクティブでないユーザーがアクティブなユーザーになる場合は、そのユーザーをアクティブなユーザーのマシンに移動します。このアプローチを採用すると、アクティブなユーザーとアクティブでないユーザーを同じマシンに置いた場合よりも、必要なハードウェアを減らすことができます。

   • ユーザーをサービスのクラス別に分けます。

     コントリビュータ、マネージャ、エグゼクティブのユーザーを、それぞれのサービスのクラス、権限、専門サービスに応じたメールストレージ容量の割り当てを提供するマシンに分けます。

4. それぞれのメールボックスで使用されるストレージの量はどのくらいですか。

   メールボックスあたりのストレージの容量を測定するときには、指定した割り当てではなくメールボックスの実際の使用率で見積もります。ごみ箱内のメッセージもディスク容量と割り当てを消費します。

5. インターネットからどれぐらいの数のメッセージがメッセージングシステムに送信されますか。

   メッセージの数は、ピークボリューム時の 1 秒あたりのメッセージ数で測定します。

6. ユーザー別ではどれぐらいの数のメッセージが送信されますか。

   • メールシステムのエンドユーザーに対して送信される数

   • インターネットに対して送信される数

   このメッセージの数も、ピークボリューム時の 1 秒あたりのメッセージ数で測定します。

7. 異なるサイズ範囲では、配信分布状態はどのようになっていますか。

   例:

   • 5K バイト未満

   • 5K バイト以上 10K バイト未満

   • 10K バイト以上 100K バイト未満

   • 100K バイト以上 500K バイト未満

   • 500K バイト以上 10M バイト未満

   • 10M バイト以上

   配信されるメッセージのサイズがわからない場合は、メールシステムの平均のメッセージサイズを使用しますが、これはサイズの範囲がわかる場合ほど有効ではありません。

   メッセージのサイズは、MTA の配信レート、メッセージストアへの配信レート、メッセージ取得のレート、およびウィルス対策用またはスパム防止用のフィルタの処理に影響を与えるため、特に重要なものです。

8. SSL/TLS を使用しますか。使用する場合は、ユーザーの何パーセントが、またどのようなタイプのユーザーが使用しますか。

   たとえば、ある組織では、ピーク時間中に IMAP 接続の 20 パーセントで SSL が使用されます。

9. 何らかの SSL 暗号化アクセラレータハードウェアを使用する予定がありますか。

10. ウィルススキャニングまたはその他の専用のメッセージ処理を使用し、その処理をすべてのユーザーに適用しますか。

    Messaging Server の設定により、MTA は専用の処理で指定された基準に一致するすべてのメッセージをスキャンする必要があり、その結果システムの負荷が増大します。

11. POP ユーザーに対し、メールへのアクセス可能頻度を制限するポリシーを適用しますか。適用する場合、どのくらいの頻度にしますか。

12. IMAP ユーザーに対し、標準のクライアントを強制しますか。それとも、各ユーザーが選択できるようにしますか。

    IMAP クライアント数が増加するとサーバーへの同時接続数も増加します。したがって、多くのフォルダを開いているパワーユーザーは、多くの同時接続を使用している可能性があります。

13. ユーザーがフォルダを共有できるようにしますか。共有できるようにする場合、すべてのユーザーに許可しますか。それとも一部のユーザーにだけ許可しますか。

これらの質問に答えることで、配備のための、準備段階としての使用率プロファイルが完成します。Messaging Server のニーズの変更に応じて、この使用率プロファイルにも修正を加えます。

その他の質問

次の質問は使用率プロファイルの作成に使用できるものではありませんが、配備のサイズ決定戦略には重要なものです。これらの質問にどのように答えるかによって、ハードウェアの追加を検討しなければならなくなる場合もあります。

1. 配備にどの程度の冗長性を持たせますか。

   たとえば、高可用性の実現を考えている場合です。どれくらいの停止時間であれば許容範囲であるかを検討してください。また、クラスタリングテクノロジが必要かどうかも検討してください。

2. どのようなバックアップ戦略と回復戦略 (障害回復、メールボックスの復元、サイトのフェイルオーバーなど) を実行しますか。回復タスクが完了するまでにどのくらいの時間を予想しますか。

3. DMZ を使って内部ネットワークと外部ネットワークを分離する必要がありますか。すべてのユーザーが内部ネットワークを使用していますか。それとも、一部のユーザーはインターネットを使って接続しますか。

   プロキシサーバー (MMP、MEM) と独立した MTA 層が必要になる可能性があります。

4. 応答時間の要件を記述してください。スループットの要件を記述してください。

5. リソースの使用条件を具体的に記述してください。CPU 使用率は平均 80 % でかまいませんか。それとも、80 % はピーク時のみですか。

6. メッセージングサーバーをいくつかの地理的に異なる場所に設置しますか。ユーザーのメールが地理的に分散配置される可能性はありますか。

7. アーカイブを使ってメールメッセージをある一定期間保管しておく必要がありますか。

8. すべてのメッセージをロギングする法律上の必要性がありますか。送受信されたすべてのメッセージのコピーを保存しておく必要がありますか。

メッセージングユーザーベースの定義

使用率プロファイルの作成が完了したら、次にそれをこの節で説明されている定義済みのユーザーベースの例と比較してみます。「ユーザーベース」は、ユーザーが送受信するメッセージサイズの範囲と、ユーザーが実行するメッセージング操作のタイプで構成されます。メッセージングユーザーは、5 つのユーザーベースに分類されます。

• 「軽量級の POP ユーザー」

• 「重量級の POP ユーザー」

• 「軽量級の IMAP ユーザー」

• 「標準的な IMAP ユーザー」

• 「標準的な Messenger Express/Communications Express ユーザー」

この節のユーザーベースの例では、ユーザーの行動を幅広く一般化しています。特定の使用率プロファイルは、このユーザーベースとは多少異なるかもしれません。これらの差異は、負荷シミュレータを実行するとき (「Messenger Express 負荷シミュレータの使用」を参照) に調整できます。

軽量級の POP ユーザー

軽量級の POP ユーザーベースは、一般に、簡単なメッセージング要件を持つ家庭のダイアルアップユーザーで構成されます。それぞれの並行クライアント接続は、1 時間あたり約 4 件のメッセージを送信します。これらのユーザーは、1 回のログインセッション中にすべてのメッセージの読み取りと削除を行います。さらに、これらのユーザーは 1 回の受信では、自分のメッセージの作成と送信をほとんど行いません。メッセージの約 80 パーセントが 5K バイト以下のサイズで、約 20 パーセントが 10K バイト以上です。

重量級の POP ユーザー

重量級の POP ユーザーベースは、高速ブロードバンドのユーザーか小規模な企業のアカウントであるのが一般的で、軽量級の POP ユーザーベースよりメッセージに関して高度な要件を持っています。このグループは、ケーブルモデムか DSL を使用してサービスプロバイダに接続します。それぞれの並行クライアント接続は、1 時間あたり約 6 件のメッセージを送信します。メッセージ受信者数の平均は 1 メッセージあたり約 2 人です。メッセージの 65 パーセントが、5K バイト以下のサイズです。このユーザーベースのメッセージの 30 パーセントが、5K バイトから 10K バイトの間のサイズです。5 パーセントのメッセージが 1M バイトを超えるサイズです。ユーザーのうち、85 パーセントが読んだ後ですべてのメッセージを削除しています。ただし、15 パーセントのユーザーは、メッセージをサーバー上に残したまま数回のログインを行なってから、メッセージを削除しています。メールは、これらのメールボックスのわずかな割合を占めるだけです。同じメッセージがサーバーから数回取得される場合もあります。

軽量級の IMAP ユーザー

軽量級の IMAP ユーザーベースは、高速なブロードバンドインターネットサービスを利用するユーザーに代表されます。このユーザーが利用するサービスには、メッセージ検索やクライアントフィルタのような高度なメッセージングシステム機能のほとんどが含まれます。このユーザーベースは、メッセージのサイズ、受信者の数、それぞれの並行接続別の送受信メッセージ数に関して、重量級の POP ユーザーベースに類似しています。軽量級の IMAP ユーザーは一般的に、一度のログインでセッションを数時間継続し、ログアウトする前にほとんどまたはすべてのメールを削除します。その結果、ログインセッション中にメールが蓄積されますが、通常はメールボックスに 20 から 30 件以上のメッセージが蓄積されることはありません。ほとんどの受信ボックスで、残っているメッセージの数は 10 件以下です。

標準的な IMAP ユーザー

標準的な IMAP ユーザーベースは、高度な企業ユーザーに代表され、営業日にはログインセッションがほぼ 8 時間継続します。これらのユーザーは、大量のメールの送受信と保管を行います。さらに、これらのユーザーの場合、メッセージの割り当ては無制限か、またはかなり大きなものとなります。受信ボックスには大量のメールが 1 日中蓄積されていき、溢れそうになったときにはすべて、または一部が消去されます。メッセージは定期的にフォルダに整理され、1 時間に何度かの割合で検索されます。それぞれの並行クライアント接続は、1 時間あたり約 8 件のメッセージを送信します。このカテゴリのユーザーの場合、送信する 1 件のメッセージの平均受信者数は 4 人で、同じメッセージサイズを重量級の POP および軽量級の IMAP のユーザーベースとして混在させます。

標準的な Messenger Express/Communications Express ユーザー

標準的な Messenger Express/Communications Express ユーザーベースは、標準的な IMAP に似ています。このユーザーベースのメッセージのサイズは、標準的な IMAP、軽量級の IMAP、および 重量級の POP ユーザーと同じです。メッセージの配信頻度も標準的な IMAP ユーザーと同じです。

組織内で、特に複数のクライアントアクセス手段を提供する場合は、おそらく複数のユーザーベースを持つことになります。ユーザーベースをこれらのカテゴリの中から決定したら、使用率プロファイルと「Messenger Express 負荷シミュレータの使用」で説明されている負荷シミュレータを使用して、そのユーザーベースのテストを行います。

Messenger Express 負荷シミュレータの使用

Messaging Server のパフォーマンスを測定するには、メッセージングユーザーベース (「メッセージングユーザーベースの定義」を参照) およびメッセージングの使用率プロファイル (「メッセージングの使用率プロファイルの作成」を参照) を負荷シミュレータへの入力として使用します。

負荷シミュレータは、ピークボリューム環境を作り出し、サーバーにかかる負荷の量を調整します。これにより、システムに過負荷をかけることなく希望する応答時間を実現するには、ハードウェア、スループット、または配備のアーキテクチャーを変更する必要があるかどうかを判断できます。

負荷シミュレータを使用するには

手順

1. テストするユーザーベース (軽量級の IMAP など) を定義します。

   必要に応じて、使用率プロファイルに最適化するように個別のパラメータを調整します。

2. テストするハードウェアを定義します。

3. 負荷シミュレータを実行し、ユーザーベースを使用してテストされたハードウェアの最大並行接続数を測定します。

4. 結果を記録して、稼働中の配備の結果と比較します。

5. ピーク負荷状態の応答時間が組織で容認されるレベルになるまで、さまざまなユーザーベースとハードウェアを使用してこのプロセスを繰り返します。

   ---

   注 –

   推奨負荷シミュレータとサポートについては、ご購入先のクライアントサービス担当者に連絡してください。

   ---

Messaging Server システムパフォーマンスの評価

負荷シミュレータを使用してハードウェアとユーザーベースの評価を行ったら、システムパフォーマンスを測定する必要があります。次のトピックで、システムの全体的なパフォーマンスを向上させる方法について説明します。

Messaging Server のメモリー使用率

配備で使用するそれぞれのマシンに、適切な量の物理メモリーが搭載されていることを確認してください。物理メモリーを追加するとパフォーマンスが向上し、ピークボリューム時でもサーバーが適切に動作するようになります。メモリーが不足していると、Messaging Server で過剰なスワッピングが発生し、効率的に動作しません。

少なくとも、1 つの CPU あたり 1G バイトのメモリーを用意してください。ほとんどの配備で、UltraSPARC® III システムの CPU 1 つにつき 2G バイトのメモリーが必要になります。

Messaging Server のディスクスループット

ディスクのスループットとは、システムでメモリからディスクに、またはディスクからメモリに転送されるデータ量のことです。このデータ転送レートは、Messaging Server のパフォーマンスに重大な影響を及ぼします。システムのディスクスループットを向上させるには、次のことを考慮します。

• 保守作業を検討し、バックアップのための十分な帯域幅があることを確認します。特にリモートバックアップの場合は、ネットワーク帯域幅にも影響を与えます。私設バックアップネットワークは、より効率的な代替バックアップ手段となります。

• ストアのパーティションと、tmp や db のようなストアデータ項目の分割を慎重に行なって、スループットを向上させます。

• 大規模な配備では、ユーザーベースが必ず RAID (Redundant Array of Independent Disks) 環境全体に分散されるようにします。

• ディスクからデータを取得する操作のスピードを向上させるために、データを複数のディスクでストライピングします。

• RAID がハードウェア上に存在しない場合は、RAID のサポートに十分な CPU リソースを割り当てます。

ディスク I/O を、帯域幅ではなく IOPS (1 秒あたりの I/O の合計) で測定することをお勧めします。システムがきわめて短い応答時間 (10 ミリ秒未満) で処理できる、個別のディスクトランザクションの数を測定する必要があります。

Messaging Server のディスク容量

サーバーシステムのディスク容量を計画する際には、環境ソフトウェア、Messaging Server ソフトウェア、およびメッセージの内容を運用するための容量、さらにトラッキングのための容量を確実に含める必要があります。可用性が要求される場合には、必ず外部ディスクアレイを使用します。ほとんどのシステムで、内部システムディスクでは 4 台までのディスクしかサポートされないため、パフォーマンスを向上させるには外部ディスクが必要となります。

メッセージストアパーティションでは、全メッセージの合計サイズに 30 % のオーバーヘッドを加えたストレージサイズが必要です。

さらに、ユーザーディスク容量を割り当てます。この容量は、通常、サイトのポリシーに従って決定されます。

配備計画には、障害回復のためのメッセージストアのバックアップ方法を含める必要があります。Messaging Server では、Solstice Backup (Legato Networker)、imsbackup ユーティリティ、およびファイルシステムスナップショットバックアップがサポートされています。バックアップメディアを遠隔地に格納した方がよい場合もあります。バックアップは、サーバーの処理に影響しない範囲で、できるだけ頻繁に実行することをお勧めします。

MTA メッセージキューのディスクサイズ決定

Messaging Server の MTA キューの動作は、配信されるのを待機しているメッセージ用の一時記憶域を提供することです。保証されたサービス提供を維持するために、メッセージは持続的方式でディスクに書き込まれます。メッセージを配信できない場合、MTA は最終的に断念してメッセージを送信者に戻すまで再試行します。

メッセージキューのパフォーマンス

MTA キューのディスクサイズ決定は、MTA のパフォーマンスを改善するための重要なステップです。MTA のパフォーマンスは、ほかのどのシステムリソースにもましてディスク I/O に直接影響されます。したがって、複数のディスクスピンドルで構成されるディスクボリュームを計画することをお勧めします。これらのディスクスピンドルは、ディスク RAID システムを使用して連結およびストライプ化されます。

MTA のパフォーマンスに問題があると、エンドユーザーはすぐにその影響を受けます。ユーザーが電子メールクライアントの「送信」ボタンを押すとき、MTA はメッセージがメッセージキューにコミットされるまで、メッセージの受信を完全には受理しません。したがって、メッセージキューのパフォーマンス改善は、エンドユーザーの立場から見ると応答時間の短縮につながります。

メッセージキューの可用性

SMTP サービスは、保証されたメッセージ配信サービスであると考えられます。これは、サービスが配信しようとしているメッセージを途中で失わないことを、メッセージングサーバーがエンドユーザーに対して保証するという意味です。MTA キューシステムを設計するときは、メッセージが失われないことを保証するためにあらゆる努力を払う必要があります。この保証は通常、さまざまな RAID 技術を使用して、冗長化されたディスクシステムを実装することによって達成されます。

メッセージキューの利用可能なディスクサイズの決定

次のいずれかの条件が発生した場合、キューのサイズは非常に大きくなります。

• サイトにおいてネットワーク接続に重大な問題がある

• MTA の設定で、メッセージの保持期間が長すぎる

• メッセージに関して、このマニュアルで扱っていない何らかの問題がある

次節以降で、これらの問題について説明します。

ネットワーク接続の問題に備えた計画

ネットワーク接続の問題により、MTA がメッセージを配信できない場合があります。そのような場合、定義された再試行間隔に従って MTA が配信を再開できるようになるまで、メッセージはキューに格納されます。

そのような中断に備えたディスク領域の計画は、「メッセージキューのサイズ決定の一般則」という単純なルールに基づいて行います。

1. 配信が予測される 1 分あたりの平均メッセージ数を決定します (N)。

2. メッセージの平均サイズ (K バイト) を決定します (S)。

3. 典型的なネットワーク接続障害の最大持続時間 (分) を決定します (T)。

ディスクキューサイズを見積もるための式は次のようになります。

ディスクキューサイズ (K バイト) = N x S x T

MTA の配信再試行設定の調整

システムがメッセージをまったく配信できなくなることがあります。この状態では、MTA は配信を再試行するまでの一定期間 (再試行間隔として定義された期間)、メッセージをメッセージキューに保留します。この状態は、MTA が配信を断念してメッセージを送信者に戻すまで続きます。メッセージが配信できなくなる理由の多くは予測不可能です。メッセージが配信できない理由には、ネットワーク接続の問題、送信先サーバーのビジー状態、ネットワークの混雑などさまざまなものがあります。

ビジー状態のサーバー上では、高ボリュームアクティビティの期間中、このような一時的に格納されるメッセージが大量に蓄積される可能性があります。大量の蓄積によって、ディスク容量の問題が発生する可能性があります。そのような蓄積を防ぐには、より短い間隔で配信を再試行するように MTA を調整します。

再試行間隔は、imta.cnf ファイルの「Channel Block」設定で設定します。このファイルの構造としては、書き換えルールとチャネルブロックの 2 つの部分から構成されています。チャネルブロックは、特定のディスクキューと、それに関連するプロセスの動作を定義します。ここでの説明に関係するのは tcp_local チャネルです。tcp_local チャネルは、企業のローカルネットワークの外部のサイト、すなわち、インターネットを経由した場所への配信を提供します。

tcp_local チャネルの再試行間隔は当初、デフォルトチャネルブロックによって設定されます。デフォルトチャネルブロックを使用すると、設定を複製することによって設定の繰り返しを防ぐことができます。

デフォルトチャネルブロックの例を次に示します。

defaults notices 1 2 4 7 copywarnpost copysendpost postheadonly
noswitchchannel immnonurgent maxjobs 7 defaulthost
red.siroe.com red.siroe.com

チャネルブロックの構造の先頭はチャネル名です。前述の例において、これは、これらの設定を持たないチャネルに適用されるデフォルトチャネルブロックです。2 番目の部分はチャネルキーワードのリストです。

notices キーワードは、メッセージ配信通知 (MDN) が送信者に返送されるまでに経過可能な時間を指定します。このキーワードは notices キーワードで始まり、それに続けて、再試行期間を設定する一連の数値を指定します。デフォルトでは、MTA は配信を再試行し、送信者に通知を返送します。これらの通知は「ポストマスター」からエンドユーザーの受信箱に送られます。

この例では、MTA は 1 日、2 日、および 4 日を経過するタイミングで配信を再試行します。7 日経過すると、MTA はメッセージを送信者に戻し、そのメッセージを配信失敗とみなします。

多くの場合、MTA のデフォルト設定で適切なパフォーマンスが得られます。場合によっては、メッセージキュー用のディスク領域不足などのリソース枯渇の可能性を回避するため、MTA を調整する必要があります。これは製品の制限ではなく、ハードウェアおよびネットワークリソースを含めた Messaging Server システム全体の制限です。

ディスクサイズに関して起こりうるこれらの問題を考慮すると、ユーザー数の多い配備では、あまり短い間隔でメッセージ配信を試みるのは好ましくない場合があります。そのような状況に該当する場合は、次に示すドキュメントを参考にしてください。

参考資料

詳細については、次のマニュアルを参照してください。

• 『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の「通知メッセージの配信間隔を設定するには」

• 『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 12 章「チャネル定義を設定する」

Messaging Server のネットワークスループット

ネットワークスループットは、一定時間内にクライアントアプリケーションとサーバー間のネットワークで転送可能なデータ量のことです。ネットワークに接続されたサーバーがクライアントからの要求に応答できない場合、通常クライアントは要求の再送信を何度も行います。再送信のたびに、システムにはオーバーヘッドと余分なネットワークトラフィックが生じます。

データの完全性とシステムのパフォーマンスを向上させて、ネットワークの混雑を解消することで、再送信の数を減らすことができます。

• ボトルネックを解消するには、ネットワークインフラストラクチャーが負荷を処理する能力を確保します。

• ネットワークを分割します。たとえば、クライアントアクセスに 100Mbps のイーサネットを、バックボーンに 1G バイトイーサネットを使用します。

• 将来の拡張に備えて十分な容量を確保するには、ネットワークを構築するときに理論最大値を使用してはなりません。

• トラフィックのフローを異なるネットワークパーティションに分割して衝突を減らし、帯域幅の使用を最適化します。

Messaging Server の CPU リソース

メッセージストア、MTA、および複合サービス (MMP および Messenger Express マルチプレクサ) だけを実行しているシステムに対して、十分な CPU を用意します。さらに、使用を計画している RAID システムにも十分な CPU を用意します。

Messaging Server アーキテクチャー戦略の構築

システムパフォーマンスのニーズを確認したあと、Messaging Server 配備のサイズ決定で次のステップは、アーキテクチャーの決定に基づいて特定のコンポーネントのサイズを決定することです。

以降の節で、2 層と 1 層のアーキテクチャーを配備する場合のサイズ決定で考慮しなければならないことについて説明します。

アーキテクチャー計画の詳細については、第 11 章「Messaging Server アーキテクチャーの開発」を参照してください。

2 層 Messaging Server アーキテクチャー

2 層アーキテクチャーでは、Messaging Server 配備を 2 つの層に分割します。1 つはアクセス層、もう 1 つはデータ層です。簡略化した 2 層アーキテクチャーでは、MMP と MTA をアクセス層に追加します。MMP が POP と IMAP メールリーダーのプロキシとして機能し、MTA が送信されたメールのリレーを行います。データ層には、メッセージストアと Directory Server を配置します。図 10–1 は簡略化した 2 層アーキテクチャーを示しています。

図 10–1 簡略化した Messaging Server の 2 層アーキテクチャー

1 層アーキテクチャーに対して、2 層アーキテクチャーには、サイズの決定に影響を与えるかもしれないいくつかのメリットがあります。2 層アーキテクチャーでは次のことが可能です。

• 1 層アーキテクチャーより簡単な保守

• SSL、ウィルススキャニング、メッセージ再処理、サービス拒否攻撃のような負荷の高いプロセスのオフロード

• 限られた停止時間内でのより簡単な拡張管理とシステムのアップグレード

次のいくつかの節で、2 層配備における特定のコンポーネントのサイズ決定方法について説明します。

メッセージストアのサイズ決定

メッセージストアのサイズ決定の目的は、ストアが処理可能な最大並行接続数を確認し、1 秒間にストアに配信されるメッセージの数を決定することです。

手順

1. 負荷シミュレータを使って集めた数値をもとに、マシン 1 台あたりのストアマシン数と並行接続数を決定します。サイズ決定ツールの詳細については、「Messenger Express 負荷シミュレータの使用」を参照してください。

2. それぞれのストアマシンに必要なストレージの容量を決定します。

3. バックアップとファイルシステム回復時の復元で必要な場合は、複数のストアパーティションまたはストアマシンを使用します。

   ご購入先のクライアントサービス担当者に、メッセージストアのユーザーの推奨最大数を尋ねてください。推奨数値を得るには、次の点を理解しておく必要があります。

   • 使用率のパターン (「Messenger Express 負荷シミュレータの使用」を参照)。

   • 配備内のハードウェアすべてのアクティブなユーザーの最大数。

   • バックアップ、復元、回復に要する時間。これらの時間は、メッセージストアのサイズが大きくなるにつれて長くなります。

インバウンド MTA とアウトバウンド MTA のサイズを決定するには

一般的には、MTA サービスはインバウンドサービスとアウトバウンドサービスとに分けます。次に、同じ方法でそれぞれのサイズを決定できます。MTA のサイズ決定の目的は、1 秒間にリレーできるメッセージの最大数を決定することです。

インバウンド MTA のサイズを決定するには、実稼働環境でのインバウンド MTA の raw パフォーマンスを知る必要があります。

手順

1. インバウンド MTA の raw パフォーマンスをもとに、SSL、ウィルススキャニングプロセス、その他の臨時のメッセージ処理を追加します。

2. 1 日のピークボリューム時のサービス拒否攻撃についても考慮します。

3. 十分な量の MTA を追加して、負荷分散と必要に応じた冗長性を確保します。

   冗長性を持たせることで、1 つ以上のタイプのマシンで、スループットや応答時間に実質的な影響を与えることなくピーク負荷を処理できます。

   さらに、一時的なメッセージの量に対して十分なディスク容量を計算して、ネットワーク上の問題やリモート MTA の機能停止に備えます。

複合サービスのサイズを決定するには

MMP と MEM のサイズを決定する場合には、システム負荷、特に MMP に対する POP と IMAP の並行接続数と、MEM に対する HTTP 接続数に基づいて計算を行います。

ここでの手順は、MEM と MMP が同じマシンにインストールされていることを前提にしています。

さらに、次のことを実行する必要があります。

手順

1. 必要に応じて、MMP と MMP のSSL 用に CPU またはハードウェアアクセラレータを追加します。

2. マシンに MEM を設定している場合は、メモリを追加します。

3. MMP の SMTP プロキシにディスクを追加します。

4. サービス拒否攻撃について考慮します。

5. 必要に応じて、負荷分散と冗長性の能力を追加します。

   インバウンド MTA ルーターの場合と同様に、配備に冗長性を持たせることでスループットや応答時間に実質的な影響を与えることなく、各タイプの 1 台以上のマシンでもピーク負荷を処理します。

単一層 Messaging Server アーキテクチャー

単一層アーキテクチャーは、アクセス層とデータ層に分割されていません。MTA、メッセージストア、そして場合によっては Directory Server が 1 つの層にインストールされます。図 10–2 は単一層アーキテクチャーを示します。

図 10–2 簡略化した Messaging Server の単一層アーキテクチャー

2 層アーキテクチャーと比較して、単一層アーキテクチャーはハードウェアに対する初期投資が少なくて済みます。しかし、1 層アーキテクチャーを選択した場合は、保守のためにかなりの停止時間を見込んでおく必要があります。

Messaging Server の単一層アーキテクチャーのサイズを決定するには

手順

1. 「2 層 Messaging Server アーキテクチャー」でのサイズ決定と同様に、メッセージストアのサイズを決定します。

2. 必要に応じて SSL 用の CPU を追加します。

3. サービス拒否攻撃について考慮します。

4. SMTP 接続数の増加に対応してディスクを追加します。

5. アウトバウンド MTA ルーター用のディスクを追加します。

   ---

   注 –

   単一層アーキテクチャーおよび 2 層アーキテクチャーにおけるメッセージングコンポーネントのサイズ決定に関する特別な手順については、ご購入先のクライアントサービス担当者に連絡してください。

   ---

第 11 章 Messaging Server アーキテクチャーの開発

この章では、Messaging Server のアーキテクチャーの設計方法について説明します。このアーキテクチャー設計により、ハードウェアリソースとソフトウェアリソースに Messaging Server コンポーネントをどのように配置するかが決定されます。

この章には、次の節があります。

• 「2 層メッセージングアーキテクチャーの理解」

• 「Messaging Server における水平スケーラビリティーと垂直スケーラビリティーの理解」

• 「高可用性の Messaging Server 配備の計画」

• 「Messaging Server アーキテクチャーのパフォーマンスの考慮事項」

2 層メッセージングアーキテクチャーの理解

2 層アーキテクチャーにより、スケーラビリティーと信頼性のために最適化された設計が可能になります。単独のホストでメッセージングシステムのすべてのコンポーネントを実行する代わりに、2 層アーキテクチャーでは、コンポーネントを異なるマシンに分割します。このようなコンポーネントの分割により、特別な専用機能が実行されます。たとえば、追加のメッセージストレージが必要になったり、より多くのアウトバウンドリレーが必要になったりするなど、特定の機能コンポーネントの負荷が増大すると、サーバーを追加して増大する負荷に対応できます。

2 層アーキテクチャーは、「アクセス層」と 「データ層」で構成されます。アクセス層は、アーキテクチャーの中で、配信、メッセージアクセス、ユーザーログイン、および認証を処理する部分です。データ層は、すべてのデータを維持する部分です。これには、LDAP マスターサーバーと、ユーザーメッセージを格納するよう設定された Messaging Server マシンが含まれます。

図 11–1 は、2 層アーキテクチャーの例を示しています。

図 11–1 2 層 Messaging Server アーキテクチャー

次でこれらの機能部分について説明します。

公衆アクセスネットワーク: Messaging Server を内部ユーザーとインターネットに接続するネットワークです。それぞれの配備で独自のネットワーク要件が定義されますが、基本的な Messaging Server の要件は、SMTP、POP、IMAP、および HTTP のような標準のプロトコルを使用したエンドユーザーとインターネットへの接続性です。

私設データネットワーク: このネットワークは、公衆アクセスネットワークと Messaging Server データの間で、セキュリティー保護された接続を提供します。セキュリティー保護されたアクセス層と、サービス全体のディレクトリ、メッセージデータセンター、および個人アドレス帳 (PAB) サーバーが含まれるデータ層で構成されます。

LDAP ディレクトリサーバー: ユーザーベースに関する情報の格納と取得に使用され るディレクトリサーバーです。ユーザーとグループエイリアス、メールホスト情報、配信設定などを格納します。設計の要件次第で、システムの同一ディレクトリを複数格納することも可能です。図 11–1 は、マスターディレクトリと 2 つのレプリカを示します。LDAP ディレクトリサーバーは、Messaging Server 製品の一部として提供されます。必要であれば、既存の Sun Java System Directory Server ディレクトリのデータを使用することも可能です。既存のディレクトリのデータ形式は、Messaging Server スキーマに準拠している必要があります。

メッセージストア: ユーザーメールを保持し、格納します。「バックエンド」と呼ばれることもあります。メッセージストアは、IMAP サーバー、POP サーバー、および Web メール (Messenger Express) サーバーのようなメッセージアクセスコンポーネントを指すこともあります。図 11–1 は、2 つのメッセージストアを持つ配備を示します。必要に応じて、さらにストアを追加することもできます。

個人アドレス帳 (PAB) サーバー: LDAP サーバー内のユーザーのアドレスを保存および取得します。このサーバーは、前述の LDAP サーバーと同一であってもなくてもかまいません。

DNS サーバー: ホスト名を IP アドレスにマップします。DNS サーバーは、メッセージを外部ドメインにルーティングするときに、どのホストに接続するかを判断します。内部的には、DNS は実際のサービスをマシン名にマップします。DNS サーバーは、Messaging Server 製品の一部ではありません。Messaging Server をインストールする前に、稼働状態の DNS サーバーをインストールする必要があります。

ロードバランサ: ネットワーク接続について、均一にバランスを取るか、複数のサーバーにアルゴリズムを適用してバランスを取ります。ロードバランサを使用すると、1 つのネットワークアドレスで多数のサーバーを表すことができるため、トラフィックのボトルネックを解消し、トラフィックフローの管理と高いレベルのサービス保証が可能になります。図 11–1 には、MMP 用、MTA 用、および MEM 用のロードバランサが含まれています。ロードバランサは Java Enterprise System 製品の一部ではありません。ロードバランサをメッセージストアまたはディレクトリマスター上で使用することはできません。ロードバランサは、MMP、MEM、Communications Express、MTA、ディレクトリコンシューマへの接続用として使用したり、Messaging Server の MTA が Brightmail 製品を使用する状況で使用したりします。

MTA インバウンドリレー: 外部 (インターネット) サイトからのメッセージを受信し、それを内部ホストおよびローカルのメッセージストアサーバーにルーティングする専用MTA です。この MTA は外部からの最初のコンタクトポイントとなるため、MTA インバウンドリレーには、権限のないリレーを防ぎ、スパムをフィルタリングし、サービス拒否攻撃に対抗する機能が追加されます。MX レコードを使えば、着信メールトラフィックの負荷を分散できます。詳細については、「MX (メール交換) レコード」を参照してください。

MTA アウトバウンドリレー: 内部または承認されたユーザーからのメールだけを受け取り、それをその他の内部ユーザーまたは外部 (インターネット) ドメインにルーティングする MTA です。単独のマシンをインバウンドリレーとアウトバウンドリレーとして使用できますが、インターネットに接続された大規模な配備では、これらの機能を 2 つの別のマシンに分割します。このようにすると、内部クライアントは、外部サイトからインバウンドするメールと競合することなく、メールを送信できます。

Delegated Administrator サーバー: 管理者に GUI 管理コンソールを提供し、管理者がユーザーの追加や削除など、より高度な管理作業を行えるようにします。

Messaging マルチプレクサ または MMP: ユーザーのメールボックスを含む特定のマシンと、関連付けられた DNS 名との結合を解除して、複数の物理マシンにわたるメッセージストアの拡大縮小を可能にします。クライアントソフトウェアは、メッセージストアのある物理的なマシンを知る必要はありません。このようにすると、ユーザーは、メールボックスが新しいマシンに移動されるたびにホストメッセージストアの名前を変更する必要がなくなります。POP クライアントまたは IMAP クライアントがメールボックスへのアクセスを要求すると、MMP はディレクトリサービスを参照してユーザーのメールボックスがある場所を検索し、そのメールボックスがある Messaging Server システムに要求を転送します。複数の MMP を使用する場合、それらをロードバランサの背後に配置する必要があります。

MEM (Messenger Express マルチプレクサ): Web メール用の HTTP アクセスサービスへの単一の接続ポイントとして機能する特別なサーバーです。すべてのユーザーがこのメッセージングプロキシサーバーに接続し、該当するメールボックスに導かれます。このため、メールユーザーには複数の Messaging Server が単一のホスト名であるかのように表示されます。Messaging Multiplexing Proxy (MMP) は POP および IMAP サーバーに接続しますが、Messenger Express マルチプレクサは HTTP サーバーに接続します。つまり、Messenger Express マルチプレクサと Messenger Express との関係は、MMP と POP や IMAP との関係と同じです。複数の MEM を使用する場合、それらをロードバランサと組み合わせて使用する必要があります。Communications Express 配備の場合、Communications Express ソフトウェアも、MEM を含む同じホストに配備されます。

2 層アーキテクチャー — メッセジングデータフロー

この節では、メッセージングシステム経由のメッセージフローについて説明します。メッセージフローがどのように機能するかは、実際のプロトコルとメッセージパス次第です。

メールの送信: 内部ユーザーから別の内部ユーザーへ

機能説明: 内部ユーザー > ロードバランサ > MTA アウトバウンドリレー 1 または 2 > MTA インバウンドリレー 1 または 2 > メッセージストア 1 または 2

アウトバウンドリレーからストアにメールを直接配信させるために、LMTP を使用するのが一般的になってきています。2 層配備では、この方法を選択できます。

内部ユーザーから別の内部ユーザー (すなわち同じ電子メールシステムのユーザー) へ宛てられたメッセージは、最初にロードバランサへ送られます。ロードバランサは、電子メールユーザーを基盤となるサイトアーキテクチャーから切り離し、高可用性電子メールサービスを提供します。ロードバランサは、その接続を MTA アウトバウンドリレー 1 または 2 のいずれかに送信します。アウトバウンドリレーはアドレスを読み取り、メッセージが内部ユーザー宛てのものかどうかを判断します。アウトバウンドリレーは、MTA インバウンドリレー 1 または 2 にメッセージを送信するか、設定によっては適切なメッセージストアに直接送信します。MTA インバウンドリレーは、そのメッセージを適切なメッセージストアに配信します。メッセージストアはそのメッセージを受け取り、メールボックスに配信します。

メールの取得: 内部ユーザー

機能説明: 内部ユーザー > ロードバランサ > MMP/MEM/Communications Express Proxy Server 1 または 2 > メッセージストア 1 または 2

メールは POP、HTTP、または IMAP のいずれかを使用して取得されます。ユーザー接続がロードバランサに受信され、MMP サーバー、MEM/Communications Express サーバーのいずれかに転送されます。次にユーザーは、接続したアクセスマシンにログイン要求を送信します。アクセス層のマシンは、ログイン要求とパスワードを検証し、ユーザー接続で指定された同じプロトコルを使用して、適切なメッセージストア (1 または 2) に要求を送信します。そしてアクセス層のマシンは、クライアントとサーバー間の残りの接続を仲介します。

メールの送信: 内部ユーザーから外部 (インターネット) ユーザーへ

機能説明: 内部ユーザー > ロードバランサ > MTA アウトバウンドリレー 1 または 2 > インターネット

内部ユーザーから外部ユーザー (すなわち異なる電子メールシステムのユーザー) へ宛てられたメッセージは、ロードバランサに送られます。ロードバランサは、電子メールユーザーを基盤となるサイトアーキテクチャーから切り離し、高可用性電子メールサービスを提供します。ロードバランサは、そのメッセージを MTA アウトバウンドリレー 1 または 2 のいずれかに送信します。アウトバウンドリレーはアドレスを読み取り、メッセージが外部ユーザー宛てのものかどうかを判断します。アウトバウンドリレーは、インターネット上の MTA にメッセージを送信します。

メールの送信: 外部 (インターネット) ユーザーから内部ユーザーへ

機能説明: 外部ユーザー > MTA インバウンドリレー 1 または 2 > メッセージストア 1 または 2

外部ユーザー (インターネット) から内部ユーザーへ宛てられたメッセージは、MTA インバウンドリレー 1 または 2 へ送られます (ロードバランサは不要)。インバウンドリレーはアドレスを読み取り、メッセージが内部ユーザー宛てのものかどうかを判断します。インバウンドリレーは LDAP 検索を使用して メッセージストア 1 または 2 のいずれに送信するかを判断し、それに従って配信します。メッセージストアはそのメッセージを受け取り、適切なメールボックスに配信します。

Messaging Server における水平スケーラビリティーと垂直スケーラビリティーの理解

「スケーラビリティー」は、メッセージングサービスの利用拡大に対応する配備の能力です。スケーラビリティーにより、ユーザー数の急激な拡大をシステムがどのくらいうまく受け入れられるかが決まります。またスケーラビリティーにより、たとえば 1 か月の間にユーザーの多くが SSL の使用を希望するなどというような、ユーザーの行動の大きな変化にシステムがどのくらいうまく適応できるかも決まります。

この節では、個別のサーバーとサーバー全体で、利用の拡大に対応するためにアーキテクチャーに追加する機能について確認します。次のトピックについて説明しています。

• 「水平的スケーラビリティーの計画」

• 「垂直スケーラビリティーの計画」

水平的スケーラビリティーの計画

水平スケーラビリティーは、アーキテクチャーにサーバーを追加することがどの程度容易であるかを示します。ユーザー数が拡大する、またはユーザーの行動が変化するにつれて、やがては既存の配備のリソースが過負荷状態になります。慎重に計画を立てて、配備のスケールを適切に拡張する方法を決めます。

配備の水平的拡張を行う場合には、リソースを複数のサーバーに分散します。水平スケーラビリティーでは、2 つの方法が使用されます。

• 「複数サーバーへのメッセージングユーザーベースの分散」

• 「冗長コンポーネントへのメッセージングリソース分散」

複数サーバーへのメッセージングユーザーベースの分散

負荷を複数のサーバーに分散するには、クライアントのメールをいくつかのバックエンドメッセージストアに均等に分割します。ユーザーをアルファベット順に分けたり、サービスのクラス別、部門、または物理的な場所別に分けたりして、特定のバックエンドメッセージストアホストに割り当てます。

MMP と MEM は、管理を容易にする目的でしばしば同じマシンに置かれます。図 11–2 に、ユーザーが複数のバックエンドサーバーに分散され、着信クライアント接続の処理にマルチプレクサを使用するサンプルアーキテクチャーを示します。

図 11–2 複数サーバーへのユーザーベースの分散

ユーザーをバックエンドサーバーに分散することで、MMP または MEM を使用するかぎり、ユーザーの管理が簡単になります。ユーザーは、メールがある 1 つのバックエンドサーバーに接続するため、すべてのユーザーに対して設定を標準化できます。この設定により、複数のサーバーの管理も容易になります。また、Messaging Server ホストへの要求増加に対応して、ホストをシームレスに追加できます。

冗長コンポーネントへのメッセージングリソース分散

電子メールが日常業務に重要な地位を占める場合は、メッセージングシステムが常に運用可能な状態であることを確実にするために、ロードバランサ、MX (メール交換) レコード、リレーのような冗長コンポーネントが必要になります。

冗長 MTA を使用することで、あるコンポーネントが動作不能に陥っても、別のコンポーネントが使用可能になります。また、リソースを冗長 MTA に分散することで、負荷の分散も行われます。この冗長性により、Messaging Server システムにフォールトトレランスも提供されます。それぞれの MTA リレーが、他の MTA リレーの機能を受け持ちます。

冗長ネットワーク接続をサーバーと MTA にインストールすることで、ネットワークの問題に対するフォールトトレランスが実現します。メッセージング配備が組織にとってより重要なものであるほど、フォールトトレランスと冗長性の検討もより重要になります。

「MX (メール交換) レコード」および 「インバウンド MTA とアウトバウンド MTA」の詳細については、次の節で説明します。

MX (メール交換) レコード

MX レコードは、1 つのホスト名を別のホスト名にマップする DNS レコードの一種です。等しい優先度の MX レコードにより、冗長化されたインバウンド MTA にメッセージがルーティングされます。たとえば、インターネットからの送信 MTA は、siroe.com に対する MX レコードが、MTAA.siroe.com および MTAB.siroe.com に対応していることを検出します。優先度が同じためにこれらの MTA の 1 つがランダムに選択され、SMTP 接続が開かれます。最初に選択された MTA が応答しなかった場合は、メールは別の MTA に送信されます。次の MX レコードの例を参照してください。

siroe.com in MX 10 MTAA.siroe.com
siroe.com in MX 10 MTAB.siroe.com

インバウンド MTA とアウトバウンド MTA

Messaging Server ホストがそれぞれ多数のユーザーをサポートしており、SMTP メールの送信負荷が高い場合、独立したインバウンド MTA とアウトバウンド MTA を使用することで Messaging Server ホストはルーティングタスクから開放されます。送信メッセージと受信メッセージの処理に異なる MTA を指定して、さらに負荷の分散を図ることもできます。

インバウンド MTA とアウトバウンド MTA の両方が、1 つの送受信 SMTP ホストとして組み合わされる場合もあります。1 つまたは複数の MTA ホストが必要であるかどうかを判断するには、アーキテクチャー全体のインバウンドおよびアウトバウンドメッセージのトラフィック特性を確認します。

ロードバランサ

負荷分散を使用すると、負荷を複数のサーバーに分散して、どれか 1 つのサーバーが過負荷状態にならないようにします。ロードバランサは、クライアントからの要求を受けて、各サーバーの CPU とメモリーの使用率を追跡するようなアルゴリズムを使用して、利用可能なサーバーに要求をリダイレクトします。ロードバランサは、共通サーバーで実行されるソフトウェアとして、純粋に外部のハードウェアソリューションとして、またはハードウェアとソフトウェアを組み合わせたパッケージとして使用可能です。

垂直スケーラビリティーの計画

垂直スケーラビリティーは、CPU の追加など、個々のサーバーマシンへのリソースの追加に関係があります。それぞれのマシンには、一定の負荷を処理できる能力があります。一般には、リソースに制限があるか、配備の拡大に応じて追加のハードウェアを購入できない場合に、配備における垂直スケーラビリティーを検討します。

配備の垂直的スケールを行うには、次のことが必要です。

• 各メッセージングコンポーネントのサイズを決定する

  「Messaging Server アーキテクチャー戦略の構築」を参照してください。

• システムのプロトタイプの負荷をテストする

  「Messenger Express 負荷シミュレータの使用」を参照してください。

• システムパフォーマンスを監視し、それに従って配備を調整する

高可用性の Messaging Server 配備の計画

高可用性は、計画された停止時間と予期しない停止時間を短時間にとどめるための配備の設計です。通常、高可用性設定は緩やかに結合された 2 つ以上のシステムで構成されたクラスタです。各システムがそれぞれのプロセッサ、メモリー、オペレーティングシステムを維持しています。ストレージはシステム間で共有されます。特別なソフトウェアがシステムをバインドし、単一点での障害からシステムが完全に自動的に回復できるようにします。Messaging Server には、Sun Cluster サービスと Veritas クラスタリングソリューションをサポートする高可用性のオプションが用意されています。

高可用性に向けた計画を作成する場合は、可用性とコストとのバランスを検討する必要があります。一般に、より可用性の高い配備では、設計と運用のコストも高くなります。

高可用性は、アプリケーションサービスの中断や停止時間によるデータアクセス機会の損失に対する保険です。アプリケーションサービスが利用不能になった場合、組織は収入、顧客、その他の機会を失うことになります。組織にとっての高可用性の価値は、停止時間のコストに直接関係します。停止時間のコストが高くなるほど、高可用性のための追加コストを正当化するのも容易になります。また、一定のレベルの可用性を保証するサービスレベル契約を組織が結んでいる場合もあります。可用性の目標を達成できない場合、財務的な打撃を直接受ける可能性があります。

詳細については、第 6 章「サービスの可用性の設計」を参照してください。

Messaging Server アーキテクチャーのパフォーマンスの考慮事項

この節では、Messaging Server コンポーネントのパフォーマンス特性を評価して、的確にアーキテクチャーを開発する方法について説明します。

この節では次の項目について説明します。

• 「メッセージストアのパフォーマンスの考慮事項」

• 「MTA パフォーマンスの考慮事項」

• 「MMP パフォーマンスの考慮事項」

• 「MEM パフォーマンスの考慮事項」

• 「Messaging Server と Directory Server のパフォーマンスの考慮事項」

メッセージストアのパフォーマンスの考慮事項

メッセージストアのパフォーマンスは、次のようなさまざまな要素に影響を受けます。

1. ディスク入出力

2. インバウンドメッセージレート (メッセージ挿入レートとも呼ばれる)

3. メッセージサイズ

4. ログインレート (POP/IMAP/HTTP)

5. IMAP および HTTP のトランザクションレート

6. さまざまなプロトコルの並行接続数

7. ネットワーク入出力

8. SSL の使用

前の要素リストは、メッセージストアに影響を与えるおおよその順序で記載されています。メッセージストレージに関するパフォーマンス問題のほとんどは、ディスクの入出力能力が不十分なことに原因があります。さらに、物理ディスク上のストアのレイアウトもパフォーマンスに影響を与えます。より小規模のスタンドアロンシステムでは、単純なディスクのストライピングでも十分な入出力が得られます。ほとんどの大規模システムでは、ファイルシステムを分離し、ストアのさまざまな部分に入出力を提供します。

メッセージングサーバーのディレクトリ

Messaging Server は 6 つのディレクトリを使用して大量の入出力活動に対応しています。これらのディレクトリは高頻度でアクセスされるため、ディレクトリごとにディスクを用意するか、より理想的には、ディレクトリごとに RAID を用意します。次の表で、これらのディレクトリについて説明します。

次の節では、Messaging Server の高頻度アクセスディレクトリについてさらに詳しく説明します。

MTA キューディレクトリ

LMTP 以外の環境では、メッセージストアシステム内の MTA キューディレクトリもかなりの頻度で使用されます。LMTP は、インバウンドメッセージが MTA キューに置かれず、ストアに直接挿入されるように機能します。このメッセージの挿入により、メッセージストアマシンの全体的な入出力要件が少なくなり、メッセージストアマシンの MTA キューディレクトリの使用頻度が大きく減少します。システムがスタンドアロンの場合、または Web メール 送信のためのローカル MTA を使用する場合は、アウトバウンドメールトラフィックのためのこのディレクトリに、まだかなりの入出力が発生します。LMTP を使用した 2 層環境では、このディレクトリが使用されることがあったとしても、ごくまれです。Messaging Server の前のバージョンでは、大規模なシステムではこのディレクトリをそれ自身のストライプまたはボリューム上に設定する必要がありました。

MTA キューディレクトリは通常、専用のファイルシステム上に配置し、メッセージストア内のメッセージファイルから分離すべきです。メッセージストアには、ディスク容量がある定義済みのしきい値を下回った場合にメッセージの配信と追加を停止するメカニズムが備わっています。しかしながら、ログディレクトリとキューディレクトリがどちらも同一ファイルシステム上に存在しており、かつそれらのサイズが増大し続けた場合、ディスク容量不足によりメッセージストアの動作が停止する可能性があります。

ログファイルディレクトリ

ログファイルディレクトリでは、設定されているログのレベルにより、さまざまな量の入出力が要求されます。メッセージストアのその他の高入出力要求とは異なり、ログディレクトリへの入出力は非同期です。典型的な配備シナリオでは、LUN 全体をログ専用には使用しません。かなり規模の大きなストア配備、または大量のログが必要な環境では、専用の LUN を使用するのが理に適っています。

ほとんどすべての環境で、メッセージストアをデータ喪失から守る必要があります。要求される損失からの保護と継続的な可用性のレベルは、RAID5 のような単純なディスク保護から、ミラーリング、日常的なバックアップ、データのリアルタイムレプリケーション、リモートデータセンターまで、さまざまです。データの保護に関しても、Automatic System Recovery (ASR) が可能なマシンから、ローカル HA 機能、自動リモートサイトフェイルオーバーまで、さまざまなものがあります。これらの決定は、ハードウェアの量とサービスの提供に必要なサポート要員の数に影響します。

mboxlist ディレクトリ

mboxlist ディレクトリには入出力が非常に集中しますが、特にサイズが大きいというわけではありません。mboxlist ディレクトリには、ストアとトランザクションログで使用されるデータベースがあります。高頻度の入出力があり、データベースを構成する複数のファイルを複数のファイルシステム間で分割できないことから、大規模な配備では mboxlist ディレクトリをそれ自身のストライプかボリューム上に配置する必要があります。これは、メッセージストアの多くの操作がデータベースにアクセスするため、垂直的スケーラビリティーの喪失の原因にもつながります。アクセスが激しいシステムでは、これがボトルネックになります。mboxlist ディレクトリの入出力パフォーマンスのボトルネックによって、ストアの raw パフォーマンスと応答時間が悪くなるだけでなく、垂直的スケーラビリティーも減少します。バックアップから高速に復旧することが要求されるシステムでは、このディレクトリを Solid State Disks (SSD) 上に配置するか、パフォーマンスの高いキャッシングアレイを使って、ファイルシステム上でサービスを継続したまま復元処理を進行できるような高い書き込みレートを許可します。

複数のストアパーティション

メッセージストアは、複数のストアパーティションをサポートしています。各パーティションを、それ自身のストライプまたはボリューム上に配置します。ストア上に配置するパーティションの数は、さまざまな要素により決定されます。明確な要素としては、サーバーのピーク負荷時の入出力要件があります。追加のストアパーティションとしてファイルシステムを追加することで、メールの配信や取得のためにサーバーで可能な IOPS (1 秒あたりの総入出力) を引き上げます。ほとんどの環境で、大きくて数が少ないストライプあるいは LUN よりも、多数の小さなストライプあるいは LUN のほうが、より大きな IOPS が得られます。

いくつかのディスクアレイを使用すると、アレイを 2 つの異なる方法で設定できます。それぞれのアレイを LUN として設定し、それをファイルシステムにマウントします。または、それぞれのアレイを LUN として設定し、それをサーバー上でストライプします。どちらも有効な設定です。ただし、複数のストアパーティション (小さいアレイでは 1 つのパーティション、または LUN のストライプセットをサーバーボリュームにした大きなアレイ上の多数のパーティション) は最適化と管理が容易です。

ただし、通常は raw パフォーマンスは、ストアパーティションの数を決定する場合の優先事項とはなりません。企業環境では、IOPS よりも容量のほうが重要となる場合が多いでしょう。また、LUN をソフトウェアストライプで設定し、1 つの大きなストアパーティションとすることも可能です。ただし、複数の小さなパーティションのほうが、一般に管理は容易です。ストアパーティションの数を決定する際に適切な最優先事項は、一般的には回復時間です。

ストアパーティションの回復時間は、いくつかのカテゴリに分類されます。

• 最初に、電源、ハードウェア、またはオペレーティングシステムの障害によるクラッシュからの回復と並行して、fsck コマンドが複数のファイルシステム上で動作します。HA プラットフォームで強く推奨され、必須となっているジャーナリングファイルシステムを使用している場合は、この要素は小さなものとなります。

• 次に、バックアップおよび回復手順が複数のストアパーティション上で並行して実行されます。メッセージストアではすべてのストアパーティションで単独のデータベースが使用されているため、この並行動作は mboxlist ディレクトリの垂直的スケーラビリティーにより制限されます。ストアパーティションあたりの 1 つのスレッドの実行と並行して、ストアクリーンアップ手順 (expire および purge) が実行されます。

• 最後に、ミラーリングまたは RAID 再同期手順が、小さな LUN で高速に実行されます。ここでは厳密な規則はありませんが、ほとんどの場合はストアパーティションを構成するスピンドルを 10 個までにすることをお勧めします。

ストレージアレイで使用されるドライブのサイズは、容量要件に対する IOPS 要件という問題になります。ほとんどの家庭用 ISP POP 環境では、「より小さなドライブ」を使用します。大規模な割り当てによる企業配備では、「より大きな」ドライブを使用します。繰り返しになりますが、すべての配備は異なっており、一連の要件を個別に検討する必要があります。

メッセージストアのプロセッサスケーラビリティー

マルチプロセスとマルチスレッドにより、メッセージストアは良好なスケール化がなされています。実際には、メッセージストアは 1 つのプロセッサから 4 つのプロセッサまで、一次直線形の比率を上回るスケール化が行われています。これは、4 つのプロセッサシステムは、1 つのプロセッサシステムを 4 つ合わせたものよりも大きな負荷を処理できることを意味します。メッセージストアは 4 から 12 のプロセッサ数についてもかなり直線形でスケール化されます。12 から 16 のプロセッサ数では、能力は増強されますが、直線形ではなくなります。LMTP を使用すると、同じサイズのストアシステムでサポートされるユーザー数は大きく増加しますが、メッセージストアの垂直的スケーラビリティーはより制限されます。

メールボックスデータベースキャッシュサイズの設定

Messaging Server は、メールボックスデータベースの呼び出しを頻繁に行います。 そのため、そのデータができるだけ迅速に返されることが重要です。メールボックスデータベースの部分をキャッシュ化すると、メッセージストアのパフォーマンスが改善されます。最適なキャッシュサイズを設定することで、メッセージストア全体のパフォーマンスを大きく向上させることができます。キャッシュのサイズは、configutil のパラメータ store.dbcachesize を使用して設定します。

メールボックスデータベースの場所を /tmp、つまり /tmp/mboxlist に定義し直すには、configutil のパラメータ store.dbtmpdir の使用をお勧めします。

メールボックスデータベースは、データページに格納されます。さまざまなデーモンにより stored、imapd、 popd などのデータベースが呼び出されると、指定されたページがキャッシュに格納されているかどうかが、システムによりチェックされます。ページがキャッシュ内に存在する場合は、それがデーモンに渡されます。存在しない場合は、システムは 1 ページをキャッシュからディスクに書き戻し、指定されたページを読み込んでそれをキャッシュに書き込む必要があります。ディスクの書き込みと読み取り回数を減らすことはパフォーマンスの向上につながりますが、それだけに、キャッシュサイズを最適に設定することが重要となります。

キャッシュサイズが小さすぎる場合は、指定されたデータをディスクから必要以上の頻度で読み込む必要があります。キャッシュサイズが大きすぎる場合は、ダイナミックメモリー (RAM) が浪費され、ディスクとキャッシュの同期に余計な時間がかかります。これら 2 つの状況の中では、キャッシュが大きすぎる場合よりも小さすぎる場合の方が、より大きなパフォーマンスの低下を招きます。

キャッシュ効率は、「ヒットレート」により測定されます。ヒットレートは、データベースがキャッシュにより処理される回数の割合のことです。最適化されたサイズのキャッシュでは、ヒットレートは 99 パーセントに達します。すなわち、要求されたデータベースページの 99 パーセントが、ディスクから取得されることなくデーモンに返されます。要求されたデータの 95 パーセント以上を返せるページ数をキャッシュが保持することを目標にしてキャッシュを設定します。キャッシュから返されるページが 95 パーセント未満の場合は、キャッシュサイズを大きくする必要があります。

キャッシュのヒットレートは、データベースコマンド db_stat を使用して測定できます。次の例では、configutil のパラメータ store.dbtmpdir を使用して、メールボックスデータベースの場所を /tmp、つまり /tmp/mboxlist に定義し直しています。db_stat コマンドは、次の場所に対して実行されます。

# /opt/SUNWmsgsr/lib/db_stat -m -h /tmp/mboxlist

2MB 513KB 604B  Total cache size.
1                   Number of caches.
2MB 520KB           Pool individual cache size.
0                   Requested pages mapped into the process’ address space.
55339               Requested pages found in the cache (99%).

この例では、ヒットレートは 99 パーセントです。これは、キャッシュサイズが最適であるか、大きすぎることを示します。これをテストするには、ヒットレートが 99 パーセント以下になるまでキャッシュサイズを小さくしていきます。ヒットレートが 98 パーセントになったら、データベースキャッシュサイズが最適化されたことを意味します。逆に、db_stat が 95 パーセント未満のヒットレートを示した場合は、store.dbcachesize パラメータを使用してキャッシュサイズを大きくします。最大サイズは、store/mboxlist ディレクトリ内のすべての *.db ファイルを合計したものになります。キャッシュサイズは、store/mboxlist ディレクトリに格納されるすべての .db ファイルの合計サイズを超えてはいけません。

ユーザーベースが変化すると、ヒットレートも変化します。このパラメータを定期的にチェックして、必要に応じて調整します。このパラメータの上限はデータベースの制約による 2G バイトです。

ディスクストライプ幅の設定

ディスクストライピングを設定するときには、システムを通過するメッセージの平均サイズにストライプ幅を合わせます。128 ブロックのストライプ幅は、通常の使用には大きすぎて、パフォーマンスに悪影響を与えます。代わりに、8、16、32 ブロック (それぞれ 4、8、16K バイトのメッセージサイズの場合) の値を使用します。

MTA パフォーマンスの考慮事項

MTA のパフォーマンスは、次の項目を含む多くの要素に影響されます。

• ディスクパフォーマンス

• SSL の使用

• インバウンドおよびアウトバウンドのメッセージ数および接続数

• メッセージのサイズ

• 対象送信先数およびメッセージ数

• MTA との接続スピードと接続待ち時間

• スパムフィルタリングまたはウィルスフィルタリングの必要性

• SIEVE 規則とその他のメッセージ解析 (変換チャネルの使用など) の使用

MTA は CPU と入出力を集中的に使用します。MTA は、キューディレクトリとロギングディレクトリという異なる 2 つのディレクトリに対し、読み書きを行います。MTA として機能する小規模なホスト (4 プロセッサ以下) では、これらのディレクトリを別のファイルシステムに分ける必要はありません。キューディレクトリでは、かなり大きい量で同期書き込みが行われます。ログディレクトリでは、小さな量の非同期書き込みが連続的に行われます。トラフィック量の多いシステム上では、これら 2 つのディレクトリを分離し、それぞれ異なるファイルシステム上に配置することを検討してください。

ほとんどのケースで、ディスクサブシステムの MTA で冗長性を導入して、ディスクの障害時にメールデータが永久に失われることを回避したいと考えるでしょう。ディスクの障害は、ハードウェアの障害で最も起こる可能性の高いものです。これは、多くの内部ディスクを持つ外部ディスクアレイやシステムが最適だということを意味します。

MTA と RAID のトレードオフ

外部 RAID コントローラデバイスとソフトウェアミラーによる JBOD アレイの使用との間にはトレードオフの関係があります。JBOD によるアプローチは、ハードウェアの購入という点では安価な場合がありますが、より多くのラックスペースと電力を必要とします。JBOD アプローチは、ソフトウェアによるミラーリングを行うことでサーバーのパフォーマンスを少し低下させ、一般的には保守コストも高くなります。ソフトウェア RAID5 は、パフォーマンスへの影響が非常に大きいため、代わりに使うことができません。そのため、RAID5 を使用する場合は、RAID5 キャッシングコントローラアレイを使用します。

MTA とプロセッサスケーラビリティー

MTA の処理能力は 8 プロセッサを超えても直線的に向上します。また、メッセージストアと同様に、1 プロセッサから 4 プロセッサまでは飛躍的にアップします。

MTA と高可用性

MTA を HA の制御のもとに置くのはあまりお勧めできません。しかし、それが保証されている環境では例外です。ハードウェアの障害時にも、メールの配信を短時間で指定した時間枠内で実行しなければならないという要件がある場合は、MTA を HA のソフトウェア制御のもとに配置します。ほとんどの環境では、ピーク負荷要件に対応できるように MTA の数を単純にいくつか増やします。これにより、1 つの MTA で障害が発生した場合でも、または大規模な配備環境で何らかの理由で複数の MTA の接続が遮断された場合でも、適切なトラフィックフローが生み出されます。

さらに、MTA の配置に関しては、MTA を常にファイアウォールの内側に配置するよう配慮します。

MMP パフォーマンスの考慮事項

MMP は、マルチスレッドの単一プロセスとして動作し、CPU とネットワークに強く依存します。MMP がディスクリソースを使用するのは、ロギング時だけです。MMP のスケーラビリティーは、2 プロセッサマシンでもっとも効率がよく、2 プロセッサから 4 プロセッサまでは直線形を下回る比率になり、4 プロセッサを超えると大きく低下します。MMP には、2 つのプロセッサを備えたラックマウントのマシンが適しています。

その他のコンポーネントソフトウェア (MEM、Calendar Server フロントエンド、Communications Express Web コンテナ、LDAP プロキシなど) を MMP と同じマシンに配置する配備の場合は、大型の 4 プロセッサ SPARC マシンの配備を検討します。そのような構成を行うことにより、管理、パッチの導入、監視などが必要なマシンの総数を減らすことができます。

MMP のサイズは、接続レートとトランザクションレートにより決まります。POP のサイズ決定は、POP 接続がほとんどアイドル状態にならないため、きわめて明快です。POP 接続では、接続が行われ、作業が行われ、そして接続が遮断されます。IMAP のサイズ決定はより複雑です。IMAP では、ログインレート、並行レート、接続のビジー状態の起こり方について確認する必要があります。MMP も、接続の待ち時間と帯域幅に多少影響を受けます。MMP はメッセージストアからクライアントに送信されるデータのバッファとして機能するため、ダイアルアップ環境では、ブロードバンド環境の場合よりも並行して処理できるユーザーの数が少なくなります。

SSL の使用率が接続のかなりの割合を占める場合は、ハードウェアアクセラレータをインストールします。

MMP と高可用性

決して MMP を HA の制御のもとに配備しないでください。個別の MMP には静的データはありません。可用性の高い環境では、1 つ以上の MMP マシンを追加して、1 つ以上の MMP が停止してもピーク負荷に対して十分な能力を確保します。Sun Fire Blade^TM Server ハードウェアを使用する場合は、Blade ラックユニット全体が停止する可能性を考慮して、適切な冗長性の配備を計画します。

MEM パフォーマンスの考慮事項

MEM では、Web メール (Messenger Express) クライアントに対して中間層プロキシが提供されます。このクライアントを使用して、ユーザーはブラウザを通じてメールにアクセスし、メールを作成できます。MEM のメリットは、メールを格納しているのはバックエンドサーバーであるにもかかわらず、エンドユーザーは MEM にだけ接続して、自分の電子メールにアクセスできることです。MEM は、ユーザーの LDAP 情報を通じて HTTP セッション情報とユーザープロファイルを管理することで、この機能を実現しています。2 番目のメリットは、すべての静的ファイルと LDAP 認証の状態が Messaging Server のフロントエンドに存在することです。このメリットにより、メッセージストアバックエンドからの Web ページレンダリングに関連した、CPU の追加要件が相殺されます。

MMP と MEM は同じサーバーセット上に配置できます。そうすることのメリットとして、少数の MMP または MEM が必要な場合に、冗長性確保のために必要なハードウェアの追加を最小限に抑えることができます。MMP と MEM を同じサーバーセット上に配置することで生じる唯一のデメリットの可能性は、1 つのプロトコルに対するサービス拒否攻撃が別のプロトコルにも影響を与えることです。

Messaging Server と Directory Server のパフォーマンスの考慮事項

Access Manager、Messaging Server、および LDAP スキーマ 2 ディレクトリを使用した大規模なインストールでは、使用するディレクトリに ACI (アクセス制御命令) を統合した方がよい場合があります。

Messaging Server を使用して Access Manager をインストールするときには、多数の ACI がディレクトリに最初にインストールされます。デフォルトの ACI の多くは、Messaging Server では不要であり使用されません。ディレクトリ内のデフォルト ACI を統合して数を減らすことにより、Directory Server のパフォーマンス、ひいては Messaging Server ルックアップのパフォーマンスを向上させることができます。

使用されていない ACI を統合および破棄する方法については、『Sun Java System Communications Services 6 2005Q4 Delegated Administrator 管理ガイド』の付録 E「Directory Server パフォーマンスのための ACI 統合」を参照してください。

第 12 章 Messaging Server トポロジの設計

この章では、「メッセージングトポロジ」の設計方法について説明します。メッセージングトポロジは、ネットワーク化されたメッセージングシステムの物理的および論理的なレイアウトを示すものです。とくに、トポロジは、ネットワーク上でデバイスがどのように配置され、互いにどのようにやり取りするかを示します。さらに、ネットワークを経由してデータを配信する方法も示します。トポロジは、データフローを規定するネットワークプロトコルに結びつけられています。

この章には、次の節があります。

• 「地理的ニーズの理解」

• 「メッセージングトポロジの設計」

• 「メッセージングトポロジ要素の理解」

• 「メッセージングトポロジ例の作成」

地理的ニーズの理解

メッセージングトポロジ設計の最初のステップは、地理的ニーズを確認することです。特に、組織内のそれぞれの場所に必要なメッセージングサービスを決定します。

1. 配備の目標を確認したら、次に配備内のそれぞれの場所に必要な機能を決定します。

2. 組織の物理的な制約、特に次の項目について理解します。

   • 使用可能な帯域幅

   • 組織内の物理的な場所間の距離

   • それぞれの物理的な場所におけるメールトランザクションレートとメールストレージの量

メッセージングトポロジの設計

トポロジを開発する前に、組織内のどこにメッセージングサービスを配置するかを決定するための戦略が必要です。目標により、組織に適用可能なトポロジには次の 4 つがあります。

• 「集中トポロジ」

  ほとんど、またはすべての主要システムコンポーネントとメッセージングサーバーを 1 箇所で一元管理します。

• 「分散トポロジ」

  ほとんどまたはすべてのシステムコンポーネントとメッセージングサーバーを複数のサイトに分散します。

• 「ハイブリッドトポロジ」

  一部のシステムコンポーネントを一元管理し、その他のコンポーネントは複数箇所に分散します。

• 「サービスプロバイダトポロジ」

  複数のドメインをホストして、より大きなカスタマベースを処理します。集中トポロジと同様に、ほとんどのシステムコンポーネントを 1 箇所で一元管理します。

集中トポロジ

集中トポロジでは、ほとんどまたはすべての、主要なシステムコンポーネントおよびメッセージングプロセスを 1 つのサイトに配置します。リモートサイトのクライアントは、Wide Area Network (WAN) により中央メッセージングサーバーと通信を行います。図 12–1 は集中トポロジを示します。

図 12–1 集中トポロジ

次のような場合に、集中トポロジの導入を検討します。

• リモートサイトでのメッセージングがミッションクリティカルなものではない。

• 小さなサイズのテキストメッセージの送受信を行うユーザーが多い。

• 組織が 1 つの物理的な場所にあるか、または小人数のユーザーが複数の場所に分散している。

• リモートサイトのサポート要員がいない。

• リモートサイトと中央サイト間で、少なくとも ISDN 以上の良質な帯域幅が使用可能。

集中トポロジの導入にはいくつかのメリットがあります。一般に、集中トポロジでは、ハードウェアとサポートのコストが低くなります。単純なメッセージングアーキテクチャーと少数のレプリカ契約によるディレクトリレプリカ構造のため、集中トポロジにすると管理がより容易になります。単純なアーキテクチャーと地理的に離れたサイト間でインストールを調整する必要がないため、集中トポロジでは迅速な配備が可能です。

ただし、集中トポロジの実施にはメリットと等しくデメリットもあります。集中化アプローチは WAN に大きく依存しています。ネットワークが正しく機能しなくなると、同じサイトのユーザーもリモートサイトのユーザーも、共に電子メールの送信ができなくなります。ネットワークの帯域幅とトラフィックにより、使用率がピークに達したときはサービスの処理が遅くなる場合があります。同じドメイン内にメッセージを送信するユーザーにとって、集中トポロジは非効率的となります。たとえば、図 12–1 では、東京サイトのあるユーザーが送信したメッセージは、同じ東京サイトの別のユーザーに配信される前にまず中央サイトに送られます。

分散トポロジ

分散トポロジでは、ほとんどまたはすべてのシステムコンポーネントとメッセージングプロセスを、複数のサイト (通常は各リモートサイト) に分散配置します。図 12–2 は分散トポロジを示します。

図 12–2 分散トポロジ

次のような場合には、分散トポロジの導入を検討することをお勧めします。

• リモートサイトでのメッセージングがミッションクリティカルなものである。

• ユーザーが大量のメッセージの送受信を行う。

• リモートサイトに大量のユーザーを抱えている。

• リモートサイトにサポート要員がいる。

• リモートサイトへの帯域幅が貧弱。

  帯域幅がトポロジ戦略に大きな影響を及ぼす場合は、帯域幅のアップグレードを検討します。一般に、帯域幅は比較的安価です。Virtual Private Networking (VPN) の導入についても検討します。VPN ではファイアウォールで保護された専用線ではなく、既存の広帯域幅インターネット網を使用します。

分散トポロジの導入にはいくつかのメリットがあります。メッセージを WAN 経由で取得する必要がないため、地域サイトのユーザーはメッセージに迅速にアクセスできます。さらに、特定地域内で送信されるメッセージに起因するメッセージングトラフィックは、集中トポロジの場合よりも少なくなります。ただし、遠隔オフィスは WAN に依存します。したがって、大量のメッセージトラフィックが遠隔オフィスで生成される場合、WAN をアップグレードする必要が出てきます。

分散トポロジを導入することのデメリットは、多くの場所で多くのハードウェアを保守しなければならないため、一般にハードウェアとサポートのコストが高くなることです。分散トポロジは複雑なため、サポートのコストも高くなります。たとえば、分散トポロジにおけるフェイルオーバーは、集中トポロジの場合よりも難しくなります。さらに、複数のサーバーを複数のサイトに分散するため、Messaging Server の初期配備に時間がかかります。

Messaging Server は LDAP ディレクトリにアクセスするため、メール配信処理においては、LDAP サーバーへの接続が不可欠となります。リモートの LDAP レプリカを使用しない場合、中央の LDAP がダウンすると、メッセージングサービスが使用できなくなります。

ハイブリッドトポロジ

ハイブリッドトポロジでは、集中トポロジと分散トポロジを組み合わせて、組織のニーズを満たします。図 12–3 はハイブリッドトポロジを示します。

図 12–3 ハイブリッドトポロジ

ハイブリッドトポロジからメリットを得られる組織として、大規模なユーザーベースをサポートできるサイトを数多く持つ組織があげられます。大規模なユーザーベースをサポートするサイトは、メッセージングサーバーを独自に保有できます。これらの大規模なサイトには、その近くに小規模な遠隔オフィスを持つ場合もあります。ただし、これらの遠隔オフィスには固有のメッセージングサーバーは必要ありません。代わりに最寄りの主要オフィスが、遠隔オフィスのためのサービスの中央ロケーションとして機能します。

サービスプロバイダトポロジ

サービスプロバイダトポロジは、本質的には大規模な集中トポロジです。通常、サービスプロバイダは複数のドメインをホストしており、企業よりも大規模なカスタマベースを抱えています。システムは集中化されており、ピーク時でも複数のユーザーをサポートする能力があります。図 12–4 はサービスプロバイダトポロジを示します。

図 12–4 サービスプロバイダトポロジ

メッセージングトポロジ要素の理解

この節では、メッセージングトポロジにおける最も一般的な要素について説明します。基本的な要素について理解を深めることで、独自のトポロジの設計が容易になります。

次のトピックについて説明しています。

• 「メッセージングトポロジのコンポーネント」

• 「MTA によるメッセージングシステムの保護」

• 「MMP と MEM の使用」

• 「ゲートウェイの使用」

メッセージングトポロジのコンポーネント

「メッセージングトポロジの設計」で、メッセージングトポロジのコンポーネントである Messaging Server、Directory Server、およびクライアントの 3 つについて簡単に説明しました。この節では、基本的なメッセージングトポロジにおけるその他のコンポーネントについて説明します。

Messaging Server: ユーザーのメールボックスを収容して管理します。また、「インターネット接続 MTA」と「MTA リレー」で説明されているように、Messaging Server の MTA 部分だけを含むサーバーとしても機能します。

クライアント: 多くの場合 Messaging マルチプレクサを通じて、Messaging Server からメッセージングサービスにアクセスします。

Directory Server: Messaging Server により名前とエイリアスの検索に使用されます。ダイレクト LDAP 検索によりメッセージがどこにルーティングされるかが決められます。

Messaging マルチプレクサ: メッセージ取得のために適切なメッセージングサービスにクライアントを接続します。

インターネット接続 MTA: インターネットからのメッセージをルーティングし、ファイアウォールを越えてリレーします。通常、Messaging Server ホストはこの機能を実行するように設定されます。

MTA リレー: インバウンド MTA は、着信メッセージを適切な Messaging Server 内の有効なアドレスにルーティングします。発信 MTA はクライアントからの発信メッセージを受け取り、LDAP にクエリを行なって送信先を検索し、メッセージを適切なサーバーに送信するか、ファイアウォールを越えてインターネットに向けて送信します。通常、Messaging Server ホストはこの機能を実行するように設定されます。

DNS サーバー: サーバー名を IP アドレスに解決し、ネットワーク内の適切なアドレスにメッセージが届くようにします。

ファイアウォール: 内部サイトのインターネットアクセスを制限します。組織内の部門間にもファイアウォールを設置することが考えられます。

MTA によるメッセージングシステムの保護

MTA を使えば、Messaging Server 配備を保護できるほか、サイトに出入りするメッセージトラフィックのフローを制御することができます。

インターネット接続 MTA は組織外のサイトからのメッセージを受信する単一窓口です。インターネット接続 MTA は、ファイアウォールを越えてインバウンド MTA、通常は別の Messaging Server に着信メッセージを送信します。

次に、インバウンド MTA はディレクトリのクエリを行なって、組織内のメッセージの送信先を判断します。インターネット接続 MTA は、ファイアウォールの外部ウォールと内部ウォールの間に位置するファイアウォールの非武装地帯 (DMZ) に配置され、インバウンド MTA 以外のサーバーについての情報にはアクセスしません。

アウトバウンド MTA は、クライアントから送信されたメッセージを受け取ります。送信 MTA は LDAP のクエリを行なって送信先を検索し、メッセージを適切なサーバーに送信するか、ファイアウォールを越えてインターネットに向けて送信します。これにより、ユーザーのためにメッセージを取得するというメッセージングサーバーとしての機能から MTA が解放されます。図 12–5 にこの概念を示します。

図 12–5 メッセージングトポロジ内の MTA

MMP と MEM の使用

MMP により、Messaging Server ホストのレイアウトをエンドユーザーから隠すことができます。その結果、メールボックスが配置されているサーバーを特定することなく、ユーザーに汎用的な MMP またはロードバランサを割り当てることができます。メッセージアクセスクライアントは、受信メッセージを取得するときに MMP を指定します。

そのようなクライアント接続と認証の際に、MMP はディレクトリ内のユーザー情報の検索を行い、ユーザーのメッセージがどこにあるかを判断します。次に、MMP はクライアントを特定のサーバーに接続します。次の図は、Messaging Server に対する IMAP4 と POP3 接続のプロキシとして MMP が機能する仕組みを示します。MEM 機能を使用することで、Messenger Express のような 複合 HTTP サービスを利用できます。図 12–6 は、Messaging Server 環境においてマルチプレクサがどのように機能するかを示します。

図 12–6 MMP の概要

複数の MMP の手前にロードバランサを配置します。MMP は通常、複数個存在します。

ゲートウェイの使用

組織には、旧バージョンのメッセージングシステムがメッセージング処理の専用メソッドとして存在する場合があります。ユーザーを移行させるまで、両方のメッセージング戦略を残しておかなければなりません。これらの旧バージョンのシステムにアクセスする場合には、SMTP ゲートウェイを使用できます。これは、新規のシステムと旧バージョンのシステム間で SMTP 接続を有効にするものです。通常、旧バージョンのシステムは、インバウンド MTA がメッセージをルーティングできるように、SMTP 接続をサポートしています。

メッセージングトポロジ例の作成

トポロジ上のニーズ、戦略、トポロジ要素について基本的な部分を理解すれば、メッセージングトポロジを作成できます。メッセージングトポロジの作成方法を示すために、この節では Siroe Corporation の例を使用します。

Siroe Corporation は、ニューヨークに本社を置くマルチメディア企業です。ロサンジェルスとシカゴに小さなオフィスを持ち、サンディエゴとミネアポリスに遠隔オフィスがあります。

ステップ 1: メッセージング目標の確認

トポロジ作成の最初のステップは、組織の目標を確認することです。第 2 章「Communications Services の要件の分析」で行なったように、Siroe のメッセージング目標を、ビジネス目標、技術的および財務的制約に分類します。

Siroe のビジネス目標

財務、マーケティング、法務、IT、エンジニアリングの各グループがニューヨークにあります。クリエイティブグループはロサンジェルスとサンディエゴにあります。テクニカルサポートグループはシカゴとミネアポリスにあります。メッセージのほとんどは、シカゴ、ロサンジェルス、ニューヨーク間で送信されています。

Siroe Corporation の従業員は、通信の主要手段を電子メールに依存しています。平均すると、従業員は 1 日に約 15 件のメッセージを送信しており、スプレッドシート、プレゼンテーション、またはアニメーション形式の添付ファイルを送信しています。

配備の計画者は、メッセージングサーバーのホストをシカゴ、ロサンジェルス、ニューヨークに配置することを決定しました。サンディエゴとミネアポリスの電子メールトラフィックは比較的少ないため、これらの遠隔オフィスは、シカゴとロサンジェルスのサーバーに接続するメールクライアントを持つだけになります。

Siroe の財務的および技術的制約

予算上の制約により、Siroe は稼働中の既存のインフラストラクチャーとハードウェアを使用し、サーバーをクリティカルなニーズのある場所に移動する予定です。24 時間年中無休のサポートは、ニューヨーク、シカゴ、ロサンジェルスのオフィスでのみ実施します。すべてのオフィスは T3 回線でインターネットに接続されます。

ステップ 2: トポロジ戦略の選択

メッセージングトポロジ作成の 2 番目のステップは、「メッセージングトポロジの設計」で説明されているトポロジ戦略の選択です。Siroe Corporation は、ビジネス目標と財務的および技術的制約の評価を行いました。その結果、次の判断を下しました。

• Messaging Server ホストを遠隔オフィスに配置する必要はなく、メールクライアントだけとします。

• 遠隔オフィスには、T3 回線による高品質の帯域幅が存在します。

• 場所にかかわらず、メールユーザーは会社全体に対して大量のメッセージの送受信を行います。

• ニューヨーク、ロサンジェルス、シカゴのユーザー数が多く、ミネアポリスとサンディエゴのユーザー数は少数です。

• ニューヨーク、ロサンジェルス、シカゴにはサポート要員が存在します。

次に、Siroe Corporation は目標と制約を一般的な設計戦略にマップしました。図 12–7 は Siroe Corporation がハイブリッドトポロジを選択したことを示します。

図 12–7 Siroe Corporation のハイブリッドトポロジ

システムに対して送受信されるメッセージトランザクションのレートはニューヨークが最も高いため、Messaging Server を最も多く配置します。ニューヨークより小規模のロサンジェルスとシカゴは、サンディエゴとミネアポリスもサポートします。ただし、これらの遠隔オフィスには固有のメッセージングサーバーは必要ありません。代わりに、シカゴとロサンジェルスが遠隔オフィスのためのサービスの中央ロケーションとして機能します。

ステップ 3: トポロジ要素の計画

メッセージングトポロジ作成の最後のステップは、「メッセージングトポロジ要素の理解」で説明されているように、実際の配備におけるトポロジ要素を計画することです。次の図は、シカゴとミネアポリスオフィスのトポロジ要素を示します。

図 12–8 シカゴとミネアポリスオフィスのための Siroe のメッセージング配備におけるトポロジ要素

作業要員の 30 パーセントがサードパーティーのベンダと請負業者で構成されるため、トポロジ内で外部ファイアウォールに内部ファイアウォールを追加して、社内の場所へのアクセスを制限します。インターネット MTA をトポロジ内に配置し、インターネットからのメッセージをルーティングし、ファイアウォールを越えてリレーします。MTA が追加され、着信メッセージと発信メッセージがルーティングされます。受信メッセージと送信メッセージを分離することにより、大量のメッセージトラフィックに対応できます。MMP は、従業員の POP および IMAP メールクライアントをMessaging Server 内のそれぞれのメールボックスに接続します。MMP を使用することで、従業員はログイン時に特定のメールホストを知る必要がなく、管理者は従業員のメールボックスを別のメールサーバーにシームレスに移動できます。

メッセージングトポロジを作成することで、配備におけるすべての要素の物理的および論理的配置を考慮できます。また、導入のやり直しを最小限にとどめることが可能になります。

第 13 章 Messaging Server セキュリティーの計画

この章では、Messaging Server 配備のさまざまなコンポーネントに対する計画を立案し、それらのコンポーネントを保護する方法について説明します。

この章には、次の節があります。

• 「配備におけるメッセージングコンポーネントの保護」

• 「メッセージングユーザー認証の計画」

• 「メッセージ暗号化戦略の計画」

配備におけるメッセージングコンポーネントの保護

この節では、メッセージング配備でコンポーネントをセキュリティーで保護する方法について説明します。

それぞれのコンポーネントで、chroot 機能を使用して、各マシンで使用できるコマンドの数を制限します。

MTA の保護

MTA をセキュリティーで保護し、処理リソースやサーバー可用性を保護します。権限を持たないユーザーからメッセージがリレーされた場合、または大量のスパムが配信された場合には、応答速度が遅くなり、ディスク容量が圧迫され、エンドユーザーのための処理リソースが消費されます。スパムはサーバーのリソースを浪費するだけでなく、エンドユーザーを煩わせるものでもあります。

権限を持たない外部のユーザーから配備を保護するだけでなく、内部ユーザーからシステムを保護する必要もあります。

次の表で、MTA に対する最も一般的な脅威について説明します。

MTA リレーに関するこの節では、配備で使用できるセキュリティーオプションについて説明します。

• 「アクセス制御」

• 「変換チャネルとサードパーティーのフィルタリングツール」

• 「RBL チェック」

• 「クライアントアクセスの制御」

• 「セキュリティー戦略の監視」

アクセス制御

アクセス制御を使用して、特定のユーザーから (へ) のメッセージをシステムレベルで拒否できます。また、特定のユーザー間でより複雑なメッセージトラフィックの制限を構成することもできます。さらに、ユーザーに独自の受信メッセージのフィルタ設定を許可し、メッセージヘッダの内容に基づいてメッセージを拒否することなどができます。

エンベロープレベルでアクセス制御を行うときは、マッピングテーブルを使用してメールのフィルタリングを行います。ヘッダベースでアクセス制御を行う場合、またはユーザー独自の制御を行う場合は、サーバー側の規則とともに一般的なメールボックスフィルタを使用します。

マッピングテーブルの概要

特定の「マッピングテーブル」を設定することにより、メールサービスへのアクセスを制御できます。MTA の多くのコンポーネントでは、テーブル検索指向の情報を利用しています。この種類のテーブルは、変換、すなわち入力文字列を出力文字列へ「マップ」するのに使用されます。マッピングテーブルは通常、2 つの列として表示されます。1 列目 (左側) には、マッチングの対象となる可能性のある入力文字列 (パターン)、2 列目 (右側) には入力文字列のマッピングの結果である出力文字列 (テンプレート) が表示されます。

次の表で、マッピングテーブルの使用により、だれがメールを送信または受信できるのか、あるいは送受信ともにできるのかを制御する方法を説明します。詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』を参照してください。

図 13–1 は、メール受信プロセスの中でマッピングテーブルが使用される場所を示したものです。

図 13–1 マッピングテーブルとメール受信プロセス

MTA サービスディスパッチャーが制御するすべてのネットワークポートで、PORT_ACCESS 拒否応答が保証されている場合は、リモートホストから最初の接続が行われた時点で、それが実行されます。FROM_ACCESS による拒否は、送信側が受信者情報またはメッセージデータを送信する前に、MAIL FROM: コマンドへの応答として行われます。SEND_ACCESS または MAIL_ACCESS による拒否は、送信側がメッセージデータを送信する前に、RCPT TO: コマンドへの応答として行われます。SMTP メッセージが拒否された場合は、Messaging Server がメッセージデータを受信せずメッセージデータを確認しないため、そのような拒否を処理するためのオーバーヘッドが最小になります。複数のアクセス制御マッピングテーブルが存在する場合、Messaging Server はそれらをすべて調べます。

メッセージが受け入れられた場合は、さらに変換チャネルとユーザー定義のフィルタによりフィルタリングされます。

マッピングテーブルによるリレー防止設定

アクセス制御マップを使うことによって、Messaging Server システムが SMTP メールのリレーに利用されるのを防ぐことができます。たとえば、あるユーザーが迷惑メールのリレーにメールシステムを使用して、システム上の多数のメールボックスに送信しようとするような場合です。

Messaging Server のデフォルトでは、ローカルの POP メールクライアントおよび IMAP メールクライアントによるリレーを含むすべての SMTP リレー操作が防止されます。「認証された SMTP を有効にする」で説明しているように、クライアントが SMTP AUTH を使用して認証せず、Messaging Server の SMTP サーバーを介して外部アドレスにメッセージを送信しようとした場合、その送信は拒否されます。このため、内部システムとリレーを許可するサブネットを認識するように設定を変更した方がよいでしょう。

外部ホストからのリレーを防止するには

ドメイン外にあるホストからドメイン外の別のホストにメッセージがリレーされるのを防ぐには、次の方法を取ります。

手順

1. 受信メールをいくつかのチャネルに分けます。例:

   • ドメイン内の IP アドレスは tcp_internal チャネルに送られます。

   • 認証されたセッションは tcp_auth チャネルに送られます。

   • その他のすべてのメールは、tcp_local チャネルに送られます。

2. 『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の「メールのフィルタリングとアクセス制御」の章で詳しく説明されているように、INTERNAL_IP マッピングテーブルを使用して、POP クライアントと IMAP クライアントからのメールを識別し、処理を許可します。

メールボックスフィルタの使用

フィルタは、メッセージに適用される 1 つ以上の条件付き処理で構成されています。Messaging Server フィルタはサーバーに保存され、サーバーによって評価されます。そのため、それらはサーバー側規則 (SSR) と呼ばれることもあります。

チャネルレベルのフィルタと MTA 全体のフィルタを作成し、不正メールの配信を防止できます。また、フィルタテンプレートを作成し、Messenger Express を使用してそれをエンドユーザーに使わせることもできます。エンドユーザーはテンプレートを使用して個人のメールボックスフィルタを構築し、不要なメールメッセージが自分のメールボックスに配送されないようにすることができます。サーバーは、次の優先順位に従ってフィルタを適用します。詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』を参照してください。

1. ユーザー単位のフィルタ

   ユーザー単位のフィルタは、特定ユーザーのメールボックスに送信されるメッセージに適用されます。フィルタテンプレートを作成し、Messenger Express クライアントを使用してそれをエンドユーザーに使わせることができます。エンドユーザーはテンプレートを使用して個人のサーバーフィルタを構築し、自分のメールボックスへのメールメッセージの配送を管理できます。フィルタにより、不要なメッセージ、リダイレクトメールなどの拒否や、メールボックスフォルダに配信されるメッセージのフィルタリングなどが行われます。

   個人用メールボックスフィルタにメッセージの許可あるいは拒否が定義されている場合は、メッセージに対してそのフィルタ処理が行われます。

   フィルタテンプレートは、Sieve スクリプトの「ハードコード」された要素をプロンプトと入力フィールドに置き換えることで、Sieve スクリプトを一般化します。Java サーブレットは、Sieve テンプレートを解析し、ブラウザ内でユーザーインタフェースを生成するのに使用されます。エンドユーザーが入力フィールドに値を入力すると、サーブレットがその値を取得して、ユーザーのディレクトリにあるプロファイルエントリ内の Sieve スクリプトに保存します。Messenger Express インタフェースを通じて、プロンプトと入力フィールドがエンドユーザーに提示されます。

   しかし、受取人がメールボックスフィルタを設定していない場合、またはユーザーのメールボックスフィルタが明示的に適用されないメッセージの場合、Messaging Server によってチャネルレベルのフィルタが適用されます。

2. チャネルレベルのフィルタ

   チャネルレベルのフィルタは、チャネルのキューに入った各メッセージに適用されます。この種のフィルタの一般的な用途は、特定のチャネルから入ってくるメッセージをブロックすることです。

   チャネルレベルのフィルタを作成するには、Sieve を使用してフィルタを書く必要があります。Sieve を使用してフィルタを作成する場合の指示の詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 17 章「メールのフィルタリングとアクセス制御」を参照してください。

   チャネルレベルのフィルタにメッセージの許可あるいは拒否が定義されている場合は、メッセージに対してそのフィルタ処理が行われます。それ以外の場合は、Messaging Server によって MTA 全体のフィルタが適用されます (該当する場合)。

3. MTA 全体のフィルタ

   MTA 全体のフィルタは、MTA のキューに入るすべてのメッセージに適用されます。この種のフィルタの一般的な用途は、メッセージの送信先とは関係なく、ダイレクトメールや受信したくないメッセージをブロックすることです。

   MTA 全体のフィルタを作成するには、Sieve を使用してフィルタを書く必要があります。Sieve を使用してフィルタを作成する場合の指示の詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 17 章「メールのフィルタリングとアクセス制御」を参照してください。

   デフォルト設定を使用した場合、それぞれのユーザーはメールボックスフィルタを所有していません。ユーザーが Messenger Express インタフェースにアクセスして 1 つまたは複数のフィルタを作成すると、そのフィルタが LDAP ディレクトリに保存されます。

変換チャネルとサードパーティーのフィルタリングツール

変換チャネルは、MTA を通じて配信されるメッセージを本文部分ごとに変換します。この処理は、サイトで提供されるプログラムかコマンドにより行われます。変換チャネルは、テキストや画像のフォーマット変換、ウイルスのスキャン、言語の変換などを行うことができます。MTA で通信するさまざまなメッセージ形式を変換することができ、特定の処理やプログラムをメッセージの本文部分に指定することができます。変換チャネルをウイルススキャニングプログラムと併用する場合は、ウイルスの除去、メッセージの保留または拒否を選択できます。特別な変換チャネル設定を使用すると、それぞれのメッセージ本文に対する適切な変換を選択できます。詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 13 章「定義済みチャネルを使用する」を参照してください。

変換チャネルのような特別な処理を行うと、システムに余分の負荷がかかります。戦略のサイズを検討する場合には、この点を考慮してください。

変換チャネルを使用すると、サードパーティーのスパム防止およびウイルス対策ソフトウェアソリューションを利用できます。また、MTA API を使用してチャネルを作成し、リモートスキャニングエンジンを起動することもできます。MTA API の詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』を参照してください。

一般に、サードパーティーのソリューションは外部サイトから保護して、バックエンドまたは中間のリレーのみで使用するのが最も適した使い方です。

Brightmail ソリューションは、Brightmail サーバーと、リアルタイムのスパム防止およびウイルス対策 (サービスプロバイダ向けのみ) 規則アップデートで構成されており、規則はメッセージングサーバーにダウンロードされます。Brightmail Logistics and Operations Center (BLOC) が電子メールプローブからスパムを受信すると、オペレータがただちに適切なスパム防止規則を作成します。次に、これらの規則が Brightmail カスタママシンにダウンロードされます。同様に、Symantec Security Response のリアルタイムのウイルス規則が Brightmail から送信されます。これらの規則は顧客の Brightmail サーバーでスパムやウイルスを検出するために使用されます。

Messaging Server では、SpamAssassin の使用もサポートされています。SpamAssassin はフリーウェアのメールフィルタで、スパムの特定に使用されます。SpamAssassin では、すべてのメッセージのスコアが計算されます。スコアは、メッセージヘッダーや本文の情報に対して一連のテストを実行することによって計算されます。各テストに成功するか失敗するかによってスコアは調整されます。スコアは正または負の実数です。スコアが一定のしきい値を超えると、スパムであるとみなされます。

Brightmail および SpamAssassin の Messaging Server に対する設定の詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 14 章「スパムとウィルスのフィルタ処理プログラムを Messaging Server に統合する」を参照してください。

RBL チェック

Mail Abuse Protection System の Real-time Blackhole List (MAPS RBL) は、スパムの発信やリレーを行なったり、スパムのサポートサービスを提供したりしてホストやネットワークを悪用している者に好意的、あるいは中立的な立場を取っていると判断されたホストとネットワークのリストです。

外部からの MAPS RBL に対する接続の比較を行うように、MTA を設定することができます。また、DNS ベースのデータベースを使用して、不特定多数宛のメールを送る可能性のある受信 SMTP 接続を判別できます。

詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 17 章「メールのフィルタリングとアクセス制御」を参照してください。

クライアントアクセスの制御

Messaging Server は、POP、IMAP、および HTTP について、サービスごとの高度なアクセス制御機能をサポートしています。Messaging Server のアクセス制御機能は、TCP デーモンと同じポートで待機するプログラムです。アクセス制御機能では、アクセスフィルタによるクライアントの識別情報の検証が行われ、そのクライアントがフィルタリング処理を通過した場合は、デーモンへのアクセスが許可されます。

大企業やサービスプロバイダのメッセージングサービスを管理する場合、これらの機能を使用して、スパム (大量メール送信) や DNS スプーフィングを行うユーザーをシステムから除外したり、ネットワークの全般的なセキュリティーを強化したりできます。

Messaging Server の TCP クライアントアクセス制御システムは、必要な場合、その処理の一部として、次のようなソケットの終端アドレスの分析を行います。

• 両方の終端の逆引き DNS 検索 (名前に基づくアクセス制御を行うため)

• 両方の終端の正引き DNS 検索 (DNS スプーフィングを検出するため)

• Identd コールバック (クライアントエンドのユーザーがクライアントホストに認識されていることを調べるため)

システムは、この情報を「フィルタ」と呼ばれるアクセス制御文と比較して、アクセスの許可または拒否を決定します。サービスごとに、個別の許可フィルタと拒否フィルタのセットを使用して、アクセスを制御します。許可フィルタは明示的にアクセスを許可し、拒否フィルタは明示的にアクセスを禁止します。

クライアントがサービスへのアクセスを要求すると、アクセス制御システムは、そのクライアントのアドレスまたは名前情報を、次の条件を使用して順番に対象のサービスのフィルタと比較します。

1. 検索は、最初の一致項目が見つかった時点で終了する。許可フィルタは、拒否フィルタより先に処理されるため、許可フィルタが優先される。

2. クライアント情報が対象のサービスの許可フィルタに一致した場合は、アクセスが許可される。

3. クライアント情報がそのサービスの拒否フィルタに一致した場合は、アクセスが拒否される。

4. どの許可または拒否フィルタにも一致しなかった場合、アクセスが許可される。例外は、許可フィルタは存在しているが拒否フィルタが存在しない場合で、その場合にはフィルタに一致しなかったアクセスは拒否される。

ここで説明するフィルタの構文は柔軟性に富んでいるため、わかりやすい簡単な方法で、さまざまなアクセス制御ポリシーを実装できます。許可フィルタと拒否フィルタは自由に組み合わせて使用できますが、大半のアクセスを許可するフィルタまたは大半のアクセスを拒否するフィルタを使用すると、ほとんどのポリシーを実装できます。

クライアントアクセスフィルタは、問題のあるドメインの数が把握できる場合に特に有効です。UBE の場合、Messaging Server はすべてのスパムメッセージを格納し処理する必要がありますが、クライアントアクセスフィルタの場合はスパムメッセージを処理する必要がありません。クライアントアクセスフィルタはドメイン全体からのメールをブロックするため、この機能は慎重に使用する必要があります。

クライアントアクセスフィルタには、次の制限があります。

• メッセージをリレーする前に、SMTP クライアントがログインする必要があります。

• クライアントアクセスフィルタは、大規模な配備には向いていません。

クライアントアクセスフィルタの詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 19 章「セキュリティーとアクセス制御を設定する」を参照してください。

セキュリティー戦略の監視

サーバーの監視は、セキュリティー戦略で重要な位置を占めます。システムに対する攻撃を識別するには、メッセージキューのサイズ、CPU の使用率、ディスクの空き容量、ネットワークの使用率を監視します。メッセージキューのサイズが異常に大きくなったり、サーバーの応答時間が長くなったりするのは、MTA リレーへの攻撃の可能性があります。また、通常とは異なるシステムの負荷パターンや接続についても調査します。ログを毎日チェックして、異常な活動がないか調べます。

メッセージストアの保護

メッセージングサーバーで最も重要なデータは、メッセージストア内のユーザーのメールです。メールメッセージは、暗号化されない個別のファイルとして格納されることに留意してください。したがって、物理的なアクセスや root アクセスからメッセージストアを保護する必要があります。

メッセージストアをセキュリティーで保護するには、ストアがインストールされているマシンへのアクセスを制限します。暗号化されないプレーンテキストのパスワードの代わりに、CRAM-MD5 パスワードまたは Digest-MD5 パスワードを使用できます。パスワードの詳細については、「メッセージングユーザー認証の計画」を参照してください。

ストアマシンの認証にパスワードを作成するだけでなく、VPN アクセス、ssh、または pam のような、マシンへのログインが許可された有効なユーザーを一覧表示するツールを使用することもあります。

また、1 層のアーキテクチャーよりも 2 層のアーキテクチャーをお勧めします。メッセージストアは、メッセージングシステムのコンポーネント中で最もディスクに負担をかける作業を行うため、フィルタリング、ウイルススキャニング、およびその他のディスクに負担をかけるセキュリティー処理を同じマシンで行わないようにします。2 層のアーキテクチャーでは、システムに余分な負荷がかかるメッセージストアと同じマシンで UBE フィルタ、リレー防止機能、およびクライアントアクセスフィルタを使用せずにすみます。代わりに、MTA がその処理を行います。さらに、ストアへのユーザーアクセスが 2 階層配備の MMP または MEM により制限され、実質的にメッセージストアにセキュリティー層を追加したことになります。

1 層のアーキテクチャーで配備を行う場合は、セキュリティー処理の追加と、SSL やウイルススキャニングなどに必要となる負荷を考慮してください。詳細については、第 10 章「Messaging Server サイズ決定戦略の計画」を参照してください。

メッセージストアにセキュリティー処理を追加する場合は、ユーザーごとにディスク割り当てを行なって、ディスクの使用率を制限します。また、空き容量が制限に近づいたときには管理アラームを出すようにします。さらに、MTA の場合と同様に、サーバーの状態、ディスク容量、サービスの応答時間を監視します。詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 18 章「メッセージストアを管理する」を参照してください。

MMP と MEM の保護

MMP はメッセージストアのプロキシとして機能するため、エンドユーザーデータへのアクセスを防ぎ、権限のないアクセスから保護する必要があります。ユーザー ID とパスワードは、基本的な認証機能となります。さらに、クライアントアクセスフィルタを使用すれば、ユーザーが特定のドメインや特定の IP アドレスの範囲にアクセスするのを制限できます。SMTP リレーサーバーのセキュリティーを提供する方法としては、SMTP 認証または SMTP AUTH (RFC 2554) をお勧めします。SMTP AUTH は、認証済みのユーザーだけに MTA を介したメール送信を許可します。詳細については、「認証された SMTP を有効にする」を参照してください。

POP サービスまたは IMAP サービスの前に、MMP を別のマシンまたは別のユーザー ID のもとに配置します。フロントエンドマシンには MMP と MTA のみを配置してから、フロントエンドマシン、メールストア、および LDAP サーバー間で、物理的にセキュリティー保護されたネットワークを構築できます。

ユーザーがインターネットからログインする場合は、Messenger Express からメッセージストアへのアクセスのセキュリティーには特に配慮が必要となります。一般的には、ストアはファイアウォールにより外部と分離します。さらに、HTTP アクセスサービスへの単一の接続ポイントとして機能する特別なサーバーとして、Messenger Express マルチプレクサ (MEM) を使用することも考えられます。MMP と同様に、MEM は、メールクライアントとの間で、暗号化されていない通信と暗号化された (SSL) 通信の両方をサポートしています。MEM は、エンドユーザーデータへのアクセスと権限のないアクセスからの保護も行う必要があります。

ログファイルを定期的に監視することで、権限のないアクセスを防ぐことができます。

メッセージングユーザー認証の計画

ユーザー認証を行うことで、ユーザーはメールクライアントへのログインとメールメッセージの取得が可能になります。ユーザー認証の方法には次のものがあります。

• 「プレーンテキストと暗号化されたパスワードによるログイン」

• 「Simple Authentication and Security Layer (SASL) による認証」

• 「認証された SMTP を有効にする」

• 「Secure Sockets Layer (SSL) による証明書ベースの認証」

プレーンテキストと暗号化されたパスワードによるログイン

ユーザー ID とパスワードは、LDAP ディレクトリに保存されます。最低限必要な長さなど、パスワードのセキュリティー基準は、ディレクトリポリシー要件によって決定されます。パスワードのセキュリティー基準は、Messaging Server 管理の一部ではありません。ディレクトリサーバーのパスワードポリシーについては、『Sun Java System Directory Server 5 2005Q1 Deployment Plannning Guide』を参照してください。

管理者は、メッセージング設定パラメータを設定して、プレーンテキストのパスワードを許可するかどうか、パスワードの暗号化を必須とするかどうかを決めることができます。詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の service.xxx.plaintextminciper パラメータ (xxx は http、pop、imap のいずれか) を参照してください。

プレーンテキストによるログインと暗号化されたパスワードによるログインは、どちらも POP、IMAP、および Messenger Express ユーザーアクセスプロトコルで使用できます。

Simple Authentication and Security Layer (SASL) による認証

SASL (RFC 2222) は、POP、IMAP、および SMTP ユーザーアクセスプロトコルの追加認証メカニズムとして機能します。Messaging Server は、表 13–3 に一覧表示されているユーザーアクセスプロトコルの SASL をサポートしています。

• CRAM-MD5 を使用する場合は、パスワードをプレーンテキスト形式で LDAP ディレクトリサーバーに保存する必要があります。

• Digest-MD5 は MMP ではまだサポートされていませんが、MMP を使用しないようにすればサポートされます。

• POP を使用する場合は、パスワードをプレーンテキストで LDAP ディレクトリサーバーに保存する必要があります。

SASL を使用する場合、セッションで SSL を使用しないと、ユーザー名とパスワードは暗号化されません。SSL の詳細については、「SSL による暗号化」を参照してください。SASL メカニズム、PLAIN および LOGIN は、認証情報を復号化しますが、情報が捕捉された場合には容易に解読されてしまいます。このような限界があるにもかかわらず、SASL は SMTP AUTH (「認証された SMTP を有効にする」を参照) と組み合わせて、システムで認証されたユーザーにだけシステムを経由したメールのリレーを許可できるため、便利です。たとえば、正当なユーザーが SMTP サーバーへの認証を受けると、SMTP サーバーで別のチャネルへの切り替えを設定できます。このようにすると、認証されたセッションからのメッセージは、認証されていないユーザーとは別の TCP チャネルから送られてくるメッセージとなります。内部ネットワークのユーザーからのメッセージも、着信接続の IP アドレスに基づいて、その他の発信元からのメッセージとは別のチャネルに切り替えできます。

SASL の詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 19 章「セキュリティーとアクセス制御を設定する」を参照してください。

認証された SMTP を有効にする

デフォルトでは、ユーザーは、メッセージ送信時に Messaging Server の SMTP サービスに接続する際に、パスワードを送信する必要はありません。ただし、SMTP へのパスワードログインを有効にすれば、認証された SMTP を使用できるようになります。

認証された SMTP (SMTP AUTH とも呼ばれる) は、SMTP プロトコルを拡張したものです。認証された SMTP を使用すると、サーバーへのクライアント認証が可能になります。認証は、メッセージの送受信時に実行されます。認証された SMTP の主な用途は、悪用される可能性のあるオープンリレーを作成することなく、オフィス外のローカルユーザーがメールを送信するのを可能にすることです。クライアントは、AUTH コマンドを使用してサーバーに対する認証を行います。

認証された SMTP は、SMTP プロトコルによるメッセージの送信をセキュリティーで保護します。認証された SMTP を使用する場合に、証明書に基づいたインフラストラクチャーを用意する必要はありません。証明書による認証については、「Secure Sockets Layer (SSL) による証明書ベースの認証」を参照してください。

認証された SMTP を使用すると、クライアントは認証メカニズムをサーバーに提示し、認証プロトコルの交換を行うことができます。さらに任意で、後続のプロトコル相互対話で使用するセキュリティー層とネゴシエーションを行うこともできます。

メールの送信に SMTP AUTH の使用を要求している場合は、適切なログを記録してメールが悪用されたケースを追跡できます。

認証された SMTP の詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の MTA に関する章を参照してください。

Secure Sockets Layer (SSL) による証明書ベースの認証

Messaging Server は、SSL プロトコルを使用して、暗号化通信とクライアントおよびサーバーの証明書ベースの認証を行います。この節では、証明書ベースの SSL 認証について説明します。SSL 暗号化の詳細については、「SSL による暗号化」を参照してください。

SSL は公開鍵暗号法の概念に基づいています。TLS (Transport Layer Security) は SSL のスーパーセットとして機能しますが、名前が混同されて使われています。

SSL をサポートしているサーバーには、証明書、公開鍵、非公開鍵、証明書、鍵、およびセキュリティーデータベースが高レベルで必要となります。これにより、メッセージの認証、機密、完全性が確保されます。

表 13–4 で、各クライアントアクセスプロトコルによる SSL 認証のサポートについて説明します。

SMTP、POP、および IMAP プロトコルは、クライアントとサーバーが SSL なしで通信を開始したあと、"start TLS" と同等のコマンドを使用して SSL 通信に切り替える方法を提供します。"start TLS" を実装していないクライアントの場合は、SMTP、POP、および IMAP サーバーが SSL を代替ポートで使用するように設定することもできます。

SSL による認証を行うには、メールクライアントはサーバーとの SSL セッションを確立し、ユーザーの証明書をサーバーに提出します。サーバーは、提出された証明書が本物であるかどうかを評価します。証明書の信頼性が確認されると、そのユーザーは認証済みであるとみなされます。

SSL を認証用途で使う場合、Messaging Server 用のサーバー証明書を入手する必要があります。この証明書は、クライアントやほかのサーバーに対して、そのユーザーのサーバーを特定します。サーバーは、クライアントの認証に使用する、信頼できる認証局 (CA) の証明書をいくつでも持つことができます。

SSL の詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 19 章「セキュリティーとアクセス制御を設定する」を参照してください。

メッセージ暗号化戦略の計画

この節では、暗号化とプライバシーソリューションについて説明します。次のトピックについて説明しています。

• 「SSL による暗号化」

• 「署名され暗号化された S/MIME」

SSL による暗号化

SSL は、IMAP、HTTP、および SMTP のアプリケーション層の下のプロトコル層として機能します。Messaging Server とそのクライアント間、および Messaging Server とほかのサーバー間におけるメッセージの転送が暗号化される場合は、通信が盗聴される危険性はほとんどありません。また、接続しているクライアントとサーバーが認証済みの場合は、侵入者がそれらのクライアントになりすます (スプーフィングする) 危険性もほとんどありません。

メッセージ送信でエンドツーエンドの暗号化を行うには、S/MIME を使用する必要があります。詳細については、「署名され暗号化された S/MIME」を参照してください。

SSL 接続の設定によりパフォーマンスのオーバーヘッドが生じると、サーバーへの負担となります。メッセージングシステムの設計とパフォーマンスの分析を行う際には、セキュリティー要件とサーバーの容量のバランスをとる必要があります。

暗号化の用途で SSL を使用する場合は、ハードウェア暗号化アクセラレータをインストールすることでサーバーのパフォーマンスを向上させることができます。一般的に、暗号化アクセラレータは、サーバーマシンに常設されたハードウェアボードとソフトウェアドライバで構成されます。

HTTP/SSL (HTTPS) を使用したクライアントとサーバー間の SSL 接続プロセスは、次のようになります。

1. クライアントが HTTPS を使用して接続を開始します。クライアントが、使用する秘密鍵アルゴリズムを指定します。

2. サーバーが認証のための証明書を送り、使用する秘密鍵アルゴリズムを指定します。クライアントと共通の最も強力なアルゴリズムが指定されます。秘密鍵が一致しない場合 (たとえば、クライアントの鍵が 40 ビットのみで、サーバーが 128 ビットの鍵を要求している場合)、その接続は拒否されます。

3. サーバーがクライアント認証を要求するように設定されている場合、この時点でクライアントに証明書が要求されます。

4. クライアントは、サーバーの証明書の正当性をチェックし、次の内容を確認します。

   • 期限が切れていない

   • 既知の署名された認証局

   • 有効な署名

   • 証明書のホスト名が HTTPS 要求のサーバーのホスト名と一致している

SSL 暗号化方式

暗号化方式とは、暗号化プロセスでデータの暗号化と復号化に使用されるアルゴリズムのことです。各暗号化方式によって強度が異なります。つまり、強度の高い暗号化方式で暗号化されたメッセージほど、承認されていないユーザーによる解読が困難になります。

暗号化方式では、キーをデータに適用することによってデータを操作します。一般的に、暗号化方式で使用するキーが長いほど、適切な解読キーを使わずにデータを解読することが難しくなります。

クライアントは、Messaging Server と SSL 接続を開始するときに、サーバーに対して、希望する暗号化用の暗号化方式とキー長を伝えます。暗号化された通信では、両方の通信者が同じ暗号化方式を使用する必要があります。一般的に使用される暗号化方式とキーの組み合わせは数多くあります。そのため、サーバーが柔軟な暗号化方式をサポートしている必要があります。暗号化方式の詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 19 章「セキュリティーとアクセス制御を設定する」を参照してください。

署名され暗号化された S/MIME

署名され、暗号化されたメッセージは、Secure/Multipurpose Internet Mail Extensions (S/MIME) メッセージと呼ばれます。S/MIME は、クライアント間の通信をセキュリティーで保護する手段です。

S/MIME を使用すると、送信者は送信する前にメッセージを暗号化できます。受信者は、受信した暗号化されたメッセージを保存し、あとで読むときだけそれを解読することができます。

Communications Express Mail に S/MIME のセキュリティー機能が追加されました。S/MIME を使用するように設定された Communications Express Mail ユーザーは、ほかの Communications Express Mail ユーザーや、Microsoft Outlook メールシステムなどの S/MIME をサポートするメールクライアントのユーザーと、署名または暗号化されたメッセージを交換できます。詳細については、「Communications Express メールで S/MIME を使用するための要件」を参照してください。

S/MIME をサポートするその他のクライアントについては、各クライアントのマニュアルで S/MIME の設定方法を確認してください。

第 14 章 Messaging Server スパム防止およびウイルス対策戦略の計画

Messaging Server は、一方的に送られてくる大量電子メール (UBE、または「スパム」) とウイルスに対処するためのツールを数多く提供しています。この章では、利用可能なさまざまなツールと対策について説明します。

この章には、次の節があります。

• 「スパム防止およびウイルス対策ツールの概要」

• 「スパム防止およびウイルス対策の考察」

• 「スパム防止およびウイルス対策配備の一般的なシナリオ」

• 「スパム防止およびウイルス対策のためのサイトポリシーの開発」

スパム防止およびウイルス対策ツールの概要

インターネットに接続されるコンピュータの数が増加し、オンラインでのビジネスが容易となるにつれて、スパムやウイルスなどを含めたセキュリティに関する問題もいっそう増加しつつあります。そのため、これらの問題に対処するための Messaging Server 配備を計画する必要があります。

Messaging Server を経由して送受信されるメールトラフィックは、さまざまな基準に基づいて異なるチャネル別に分類できます。この基準には、発信元および送信先電子メールアドレスや発信元 IP アドレスまたはサブネットが含まれます。これらのさまざまな電子メールフローやチャネルに異なる処理特性を適用できます。その結果、これらのチャネル上で、さまざまなアクセス制御、メールフィルタ、処理の優先順位、およびツールをさまざまな方法と組み合わせで使用できます。たとえば、ドメイン内から発信されたメールを配備の外部から発信されたメールと区別して処理できます。

チャネルベースのメッセージフロー以外の便利な分類方法として、メーリングリストトラフィックがあります。Messaging Server に送信されてくる特定のメーリングリストのトラフィックは、数多くのチャネルを経由して受信し、また数多くの異なるチャネルに分けて送信できます。メーリングリストを使用すると、チャネルではなく、リスト自体を基準に考えるのが有用であることがわかります。Messaging Server はこの分類を認識し、数多くのチャネル固有のスパム対策ツールをメーリングリスト固有の方法で適用できます。

Messaging Server で使用できるスパム防止およびウイルス対策ツールの概要を次で説明します。

• アクセス制御: 既知のスパム発信元からのメールを排除し、組織内でメールを送受信可能なユーザーを制御できるようにします

• メールボックスフィルタリング: ユーザーが Web インタフェースを通じて独自のスパムフィルタを管理し、メールボックスに配信されるメールの特性を制御できるようにします

• アドレス検証: 不正な発信者アドレスを持つメールを拒否します

• Real-time Blackhole List: 既知のスパム発信元のリストを責任を持って管理し、常に更新を行う Mail Abuse Protection System の Real-time Blackhole List (MAPS RBL) に基づき、スパムの発信元として認識された発信者からのメールを拒否します

• リレーブロッキング: メールシステムの悪用者が、メールシステムをリレーとして使用して大量の受信者にスパムを送信しようとするのを防ぎます

• 認証サービス: Simple Authentication and Security Layer (SASL) プロトコルを使用して、SMTP サーバー内でのパスワード認証を有効にします

• サイドライニング: スパムの可能性のあるメッセージを保留するか、場合によっては削除します

• 総合追跡: 信頼性の高いメカニズムを使用してメッセージの発信元を特定します

• 変換チャネル: サードパーティーのウイルス対策およびスパム防止製品を統合します

これらのツールは個別に使用したり、組み合わせて使用したりできます。単独ですべてのスパムを防ぐことのできるツールはありません。しかし、組み合わせて使用することで、これらのツールはメールシステムの不正使用を防ぐ効果的な手段となります。次の節で、これらのツールについてより詳しく説明します。詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』を参照してください。

アクセス制御

Messaging Server には、さまざまな検証基準に従ってメールを拒否できる汎用の機能が備わっています。この基準には、メッセージの発信元および送信先電子メールアドレスや発信元 IP アドレスが含まれます。たとえば、このメカニズムを使用して、特定の発信者やドメイン全体 (たとえば spam@public.com というドメイン全体) からのメールを拒否できます。スクリーニング情報のために大量のリストが必要な場合は、アクセス基準を格納したデータベースでリストを拡張することもできます。UBE 関連以外でも、これと同じアクセス制御のメカニズムは、特定のチャネルからのメール送信を許可または禁止された内部ユーザーのデータベースを管理するのに適しています。たとえば、インターネットメールの送受信を許可するか禁止するかを、ユーザー別に制限できます。

詳細については、「アクセス制御」を参照してください。

メールボックスフィルタリング

Messaging Server には、ユーザー別、チャネル別、およびシステム全体で使用できるメールフィルタがあります。ユーザー別チャネルは、Messenger Express のどの Web ブラウザからでも管理が可能です。これらのフィルタを使用して、ユーザーは自分のメールボックスに配信されるメールを制御できます。たとえば、「簡単に儲かる」式の UBE をユーザーが受け取りたくない場合、そのような件名のメールを拒否するよう指定できます。Messaging Server のメールフィルタリング機能は、Internet Engineering Task Force (IETF) により開発された Sieve フィルタリング言語 (RFC 3028 および 3685) に基づいています。

詳細については、「メールボックスフィルタの使用」を参照してください。

Brightmail や SpamAssassin のようなサードパーティーのコンテンツフィルタリングソフトウェアを使用して、コンテンツベースなウイルススキャニングのフィルタリングを実装することも可能です。詳細については、「スパム防止およびウイルス対策の考察」を参照してください。

アドレス検証

UBE メッセージは、しばしば不正発信者のアドレスを使用します。Messaging Server SMTP サーバーは、メッセージを不正な発信者のアドレスと照合させることで、これを利用できます。発信者のアドレスが DNS サーバーに対するクエリにより有効なホストネームに対応していないと判断された場合、そのメッセージは拒否されます。ただし、DNS をこのように使用する場合は、パフォーマンスが低下する可能性があります。

『Sun Java System Messaging Server 6 2005Q4 管理ガイド』で説明されているチャネルキーワー ド mailfromdnsverify を使用して、チャネル別ベースのアドレス検証を有効にします。

Real-time Blackhole List

Mail Abuse Protection System の Real-time Blackhole List (MAPS RBL) は、発信元 IP アドレスによって識別された既知の UBE 発信元のリストを動的に更新します。Messaging Server SMTP サーバーは MAPS RBL をサポートしており、MAPS RBL が UBE の発信元として認識した IP アドレスからのメッセージ受信を拒否できます。MAPS RBL は、インターネット DNS を使用した無料サービスです。

詳細については、次を参照してください。

http://mail-abuse.org/rbl

MTA Dispatcher の ENABLE_RBL オプションを使用すると、Messaging Server SMTP サーバーで RBL を有効にできます。

リレーブロッキング

総合的な UBE 対策としては、アクセス制御、メールボックスフィルタリング、アドレス検証、RBL を使用して UBE を受け取らないようにする対策と、システムが不正に利用されてメールをほかのシステムにリレーしてしまうことを防ぐ対策が必要です。後者は、リレーブロッキングと呼ばれます。リレーブロッキングの最も単純な方法は、非ローカルシステムからのリレーを拒否しながら、ローカルユーザーとシステムにはメールのリレーを許可することです。IP アドレスを選別の基準として使用すると、ローカルと非ローカルを簡単かつ安全に判断できます。デフォルトでは、Messaging Server はインストール時にリレーブロッキングを行うように設定されます。詳細については、「マッピングテーブルによるリレー防止設定」を参照してください。

認証サービス

Messaging Server の SMTP サーバーには Simple Authentication and Security Layer (SASL、RFC2222) が実装されています。SASL は POP クライアントと IMAP クライアントで使用することができ、SMTP サーバーへのパスワードベースのアクセスを提供しています。SASL の一般的な使用方法は、認証を受けた外部ユーザーにメールのリレーを許可することです。これにより、自宅からまたは出張中に ISP を使用するローカルユーザーに共通の問題が解決されます。そのようなユーザーは、メールシステムに接続するときに、ローカルとは異なる IP アドレスを使用します。発信元 IP アドレスのみを考慮するリレーブロックでは、これらのユーザーのメールはリレーされません。この問題は、SASL を使用してこれらのユーザーの認証を可能にすることで解決できます。一度認証を受けたユーザーは、メールのリレーが許可されます。

サイドライニング

前述したアクセス制御のメカニズムでは、疑わしいメッセージの処理を保留しておき、あとで手動で検査することもできます。あるいは保留する代わりに、送信先アドレスを変更して疑わしいメールを特定のメールボックスに配信したり、警告なしで削除したりすることもできます。この対策は、UBE が既知の固定された発信元から送られてきたものである場合に有効で、これを完全に受信拒否してしまうと、悪用者が発信元を変更してしまうだけの結果となってしまいます。Messaging Server のメーリングリストでも同様の機能を使用できます。警告なしでメールを削除する場合には、正当な送信者が影響を受けないよう慎重に行う必要があります。

総合追跡

Messaging Server の SMTP サーバーは、すべての受信メールメッセージに関する重要な発信元情報を検出し、記録します。この情報には、発信元 IP アドレスとそれに対応するホスト名が含まれます。検出されたすべての情報は、設定によりログファイルとともにメッセージの追跡フィールド (たとえば、Received: ヘッダー行) に記録されます。そのような信頼性の高い情報を利用できることは、ヘッダが詐称されることの多い UBE の発信元を突き止めるのに重要なことです。各サイトでは任意のレポートツールを使用して、プレーンテキストで保存されているこの情報にアクセスできます。

変換チャネル

変換チャネルは非常に汎用的な目的で使われるインタフェースです。チャネル上でスクリプトやプログラムを呼び出して、電子メールメッセージの本文を任意に処理できます。変換プログラムは、それぞれの MIME のメッセージ全体ではなく本文をプログラムまたはスクリプトに渡し、その本文をプログラムまたはスクリプトの出力に置き換えます。変換チャネルは、テキスト形式から PostScript 形式へというようにファイル形式を変換したり、ある言語を別の言語に変換したり、会社の機密情報のためにコンテンツフィルタリングを実行したり、ウイルスを検索したり、メッセージを別のものに置き換えたりするのに使用できます。

サードパーティー製品との統合

Messaging Server の変換チャネルを使用すると、サードパーティーの供給元が提供するコンテンツフィルタリングソフトウェアを配備に統合できます。チャネルキーワードは、Brightmail または SpamAssassin のようなスパム防止およびウイルス対策製品を使用したメールフィルタリングを行うのに使用されます。MTA を設定して、すべてのメッセージまたは特定のチャネルを経由するメッセージのフィルタリングを行なったり、ユーザー別のレベルでフィルタの精度を設定したりできます。スパム防止とウイルス対策のいずれか、または両方の使用を選択できます。SpamAssassin はスパムのフィルタリングのみを行います。

Sieve の広範囲なサポートにより、スパムやウイルスであると判定されたメッセージの処理設定に大きな柔軟性を持たせることが可能となりました。ウイルスとスパムの削除をデフォルトの動作とするか、スパムを特定のフォルダに集めることができます。ただし、Sieve を使用する場合は、メッセージのコピーを特別なアカウントに転送するか、カスタムヘッダーを追加するか、spamtest Sieve 拡張を使用して、SpamAssassin から返されるレイティングに基づいて異なる動作を行うことができます。

スパム防止およびウイルス対策の考察

この節では、スパム防止またはウイルス対策の技術を使用した配備を計画する場合の留意事項について説明します。

スパム防止およびウイルス対策を配備する場合のアーキテクチャー上の問題

Messaging Server MTA は、Brightmail や SpamAssassin のようなメールフィルタリングシステムと同じシステムでも、別のシステムでも使用することができます。MTA をメールフィルタリングサーバーから分離することのメリットは、ハードウェアを追加してサーバーのクローンを使用すれば、簡単にフィルタリングの処理能力を上げられることです。システムの能力に余裕があり、過負荷状態になっていない場合は、メールフィルタリングサーバーソフトウェアを MTA と同じサーバーに置くことができます。

一般には、MTA がメールのフィルタリングに使用する Brightmail サーバーの「ファーム」を配備することを検討します。MTA が Brightmail サーバー名のリストを使用するように設定すると、MTA の負荷を分散できます。この負荷分散機能は、Brightmail SDK により可能になります。Brightmail サーバーのファームを導入するメリットは、より多くの処理パワーが必要な場合に、Brightmail サーバーを追加するだけで対応できることです。

メールフィルタリング製品は、一般に高い CPU 占有率を要求します。MTA とメールフィルタリング製品をそれぞれ専用のマシンに分けるアーキテクチャーを構築することで、メッセージング配備の全体的なパフォーマンスを向上させることができます。

メールフィルタリングサーバーの CPU 占有率が高い傾向にあるため、フィルタリングの対象となる MTA ホスト以上の数のメールフィルタリングシステムを使用するアーキテクチャーに行き着く場合もあります。

大規模な配備では、それぞれのインバウンドメールとアウトバウンドメールの MTA プールに対応する、サーバーのインバウンドおよびアウトバウンドフィルタリングプールを構築することも検討します。また、「スイング」プールを構築して、必要とされる状況に応じてインバウンド、アウトバウンドのいずれかのプールとして機能させることもできます。

その他の配備全般と同様に、メールフィルタリング層を常時監視する必要があります。経験上、CPU 占有率 50% をしきい値とするのが良い指針です。このしきい値に達したら、メールフィルタリング層の能力増強を検討する必要があります。

RBL の実装

一般的には、RBL を実装するとすぐにスパムを減らすことができます。MTA によって RBL が実装されれば、スパムを少なくとも 10% 以上、すぐに減らすことができます。この数字が 50% にまで達する場合もあります。

RML と Brightmail とは併用できます。Brightmail が一定の時間内に特定の IP アドレスの電子メール 100 件のうち 95 件を処理した場合、その IP アドレスを RBL に追加する必要があります。Brightmail の分析を行う際、Brightmail のメール判定基準のために RBL を調整できます。この調整により、RBL はスパムが集中する場合の処理に十分に備えられます。

スパム防止およびウイルス対策配備の一般的なシナリオ

この節では、Brightmail および SpamAssassin の一般的な配備例について説明します。詳細については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』を参照してください。

Symantec Brightmail の使用

Symantec Brightmail には、次の一般的な配備シナリオがあります。

• ローカルメッセージストア (ims-ms チャネル) に届く受信メッセージの処理

• インターネット (tcp-local チャネル) に送られるメッセージの処理

• インターネット (tcp-local チャネル) から届くメッセージの処理

• 特定のドメインに送られるメッセージの処理 (per-domain オプション)

• 特定のユーザーに送られるメッセージの処理 (per-user オプション)

• Class-of-Service オプションとしての Brightmail 処理の設定

Brightmail がスパムとウイルスの両方のチェックを実行する場合、MTA のメッセージスループットは 50% ほど低下する可能性があります。MTA のスループットを維持するには、各 MTA につき 2 台の Brightmail サーバーが必要です。

SpamAssassin の使用

Messaging Server では、SpamAssassin の使用がサポートされています。SpamAssassin はフリーウェアのメールフィルタで、スパムの特定に使用されます。SpamAssassin は、Perl や一連のアプリケーションで記述されたライブラリと、SpamAssassin のメッセージングシステムへの統合に使用するユーティリティーで構成されています。

SpamAssassin では、すべてのメッセージのスコアが計算されます。スコアは、メッセージヘッダーや本文の情報に対して一連のテストを実行することによって計算されます。各テストに成功するか失敗するかによってスコアは調整されます。スコアは正または負の実数です。スコアが一定のしきい値 (通常 5.0) を超えると、スパムであるとみなされます。

SpamAssassin には高い設定性があります。テストはいつでも追加したり削除したりでき、既存テストのスコアは調整できます。これらはすべてさまざまな設定ファイルを通じて実行されます。SpamAssassin の詳細については、SpamAssassin の Web サイトを参照してください。

http://www.spamassassin.org

Brightmail のスパムおよびウイルススキャンライブラリに接続する場合と同じ方法で SpamAssassin spamd サーバーに接続できます。

Symantec AntiVirus Scan Engine (SAVSE) の使用

Messaging Server は SAVSE の使用をサポートします。SAVSE は、TCP/IP サーバーアプリケーションおよび通信用の API であり、高性能なウイルススキャニングを提供します。SAVSE は、ネットワークインフラストラクチャーデバイス経由で送受信されるトラフィックやそれらのデバイス上に格納されているトラフィックを保護するように設計されています。

スパム防止およびウイルス対策のためのサイトポリシーの開発

スパムとスパムのリレーを防止するためのポリシーを開発する場合には、スパムの防止機能と電子メールがサイトにタイムリーに配信されることのバランスを取る必要があります。したがってベストのポリシーは、処理時間があまり長くない判定基準をコアとして最初に配置して、スパムの大半を捕捉することです。最終アーキテクチャーでストレステストを行なったあとに、この判定基準のコアセットを定義できます。最初の判定基準は次の内容で始めます。システムを配備したら、捕捉されたスパムと捕捉されなかったスパムを分析してシステムの微調整を行い、必要に応じて機能を入れ替えたり、新機能を追加したりします。

サイトのスパム防止およびウイルス対策ポリシーの開始点として、次の判定基準を使用します。

• リレー防止は、ORIG_SEND_ACCESS の設定により行います。この構造により、登録者とパートナーのユーザーだけがアクセスを許可され、SMTP 経由でメールを外部に送信できます。

• 認証サービスを使用して、ローミングユーザーを検証します。これらのユーザーは、識別情報が確認された後で SMTP 経由の外部への送信を許可されます。

• システム全体のメールボックスフィルタを使用して、件名行をチェックしてスパムに共通の言い回しをチェックする機能を実装します。

• holdlimit キーワードを使用して、メール受信者の最大数を設定します。これにより、スパムの可能性のあるトラフィックを保留にできます。受信者数の初期値を 50 に設定しておいて、ある程度の期間監視を続けてから、必要に応じて増減します。

• ポストマスターがマニュアルで利用する、専用のダミーアカウントを設定して、そのアカウントに送られてくるスパムを監視して新しいスパムサイトをつきとめます。

• ウイルスが検出されたメッセージを送信者に返送すべきではありません。そして、受信対象となっているユーザーにも転送すべきではありません。それが無意味である理由は、このようなメッセージでは、ウイルスがメールを生成し、送信者アドレスを偽造しているからです。ウイルスに感染しているメッセージが重要なものであることはきわめて稀です。

• 感染しているメッセージは、ウイルスに関する情報を収集してリスト化するウイルス対策エンジンに送ります。そのような情報を利用して、システム管理者に新しいウイルスやワームの発生を通知するレポートを作成できます。

第 15 章 Messaging Server インストール前の考慮事項と手順について

この章では、Messaging Server をインストールする前に検討しなければならない考慮事項と、実行しなければならない手順について説明します。Java Enterprise System インストーラの実行手順については、『Sun Java Enterprise System 2005Q4 Installation Guide for UNIX』を参照してください。

この章には、次の節があります。

• 「Messaging Server インストールの考慮事項」

• 「Messaging Server インストール用ワークシート」

• 「設定する Messaging Server コンポーネントの選択」

• 「sendmail デーモンを無効にする」

Messaging Server インストールの考慮事項

この節では、Messaging Server のインストールの準備のための考慮事項について説明します。

• リソースの競合: サーバー間のリソースの競合を回避するには、Messaging Server をインストールするホストとは別のホストに Directory Server をインストールすることを検討してください。

• インストール権限: Messaging Server をインストールするには、ルート としてログオンする必要があります。

• Messaging Server ベースディレクトリ: Messaging Server は、msg_svr_baseと呼ばれるディレクトリ (たとえば /opt/SUNWmsgsr) にインストールされます。このディレクトリは、既知のファイル配置構造 (ファイルディレクトリパス) を持っています。

• サーバーのアップグレード: Messaging Server ホストにその他のコンポーネント (Web Server、Directory Server、Access Manager、および管理サーバー) をインストールしない場合は、これらのコンポーネントのアップグレードは不要で、Messaging Server は問題なく動作します。同じマシンにその他のコンポーネントがインストールされている場合は、Messaging Server とともにそのコンポーネントをアップグレードする必要があります。

• ポート番号の競合: 同じマシンに特定の製品をインストールすると、ポート番号の競合が起こる場合があります。次の表は、ポート番号が競合する可能性についてまとめたものです。

可能であれば、ポート番号が競合する製品は別のホストにインストールします。それができない場合は、競合する製品のいずれかでポート番号を変更する必要があります。ポート番号を変更するには、configutil ユーティリティーを使用します。手順については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』を参照してください。

次の例では、configutil の service.http.port パラメータを使用して、Messenger Express の HTTP ポート番号を 8080 に変更しています。

configutil -o service.http.port -v 8080

Messaging Server インストール用ワークシート

Messaging Server をインストールするときに、次のインストールワークシートを使用して記録をつけておくと、インストールプロセスで役立ちます。これらのインストールワークシートは、Messaging Server を何度もインストールしたり、アンインストールしたり、アップグレードのためにアップグレードしたりする際に再使用できます。

インストール中に指定したすべてのポート番号と、そのポート番号を使用する特定のコンポーネントを記録しておきます。

ワークシートには次のものがあります。

• 「Directory Server インストール用ワークシート」

• 「管理サーバー初期実行時設定用ワークシート」

Directory Server インストール用ワークシート

Java Enterprise System インストーラ、または以前の Directory Server インストールにより、Directory Server をインストールできます。Directory Server のインストール情報と設定パラメータを表 15–2 に記録します。管理サーバーと Messaging Server のインストールと設定を行うときや、Messaging Server の実行時初期設定を行うときに、これらのパラメータが必要となります。その他の情報については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』を参照してください。

管理サーバー初期実行時設定用ワークシート

Java Enterprise System インストーラを通じて管理サーバーの初期実行時設定プログラムを実行するときは、インストールパラメータを次の表に記録します。これらのパラメータの中には、Messaging Server 初期実行時設定に必要なものがあります。いくつかの質問項目については、「Directory Server インストール用ワークシート」も参照してください。

設定する Messaging Server コンポーネントの選択

Messaging Server ソフトウェアをインストールするときに、Java Enterprise System インストーラによりすべての Messaging Server がインストールされます。次に、Messaging Server 設定プログラムを使用して、Messaging ホスト上で適切なMessaging Server コンポーネント (MTA、メッセージストア、Messenger Express、MMP) を選択します。

次の表は、それぞれのタイプの Messaging ホストで設定する必要のあるコンポーネントを示します。

LMTP 配信メカニズムを設定するには、MTA とバックエンドストアの両方の設定が必要です。LMTP の設定手順については、『Sun Java System Messaging Server 6 2005Q4 管理ガイド』の第 15 章「LMTP 配信」を参照してください。

sendmail デーモンを無効にする

Messaging Server のインストールに先立ち、もしも sendmail デーモンが実行中であれば無効にしておくことをお勧めします。Messaging Server SMTP サーバーが実行する Dispatcher には、ポート 25 を割り当てる必要があります。ポート 25 で sendmail デーモンが実行されていると、Dispatcher をポート 25 に割り当てることができません。

sendmail デーモンを無効にするには

手順

1. /etc/init.d ディレクトリに移動します。

   cd /etc/init.d

2. sendmail が実行されている場合は、停止します。

   ./sendmail stop

3. /etc/default/sendmail に MODE="" を追加します。

   sendmail ファイルが存在しない場合は、ファイルを作成し、MODE="" を追加します。

   この修正の追加は、ユーザーが誤って sendmail start を実行したり、パッチにより sendmail が再起動されたりする場合に、sendmail がデーモンモードで起動するのを防ぎます。

   ---

   注 –

   場合によっては (特に Solaris 10 上において)、/etc/init.d/sendmail stop コマンドを実行したあとでも、sendmail が自動的に再起動されます。その場合は、次のコマンドを使って sendmail プロセスを停止します。

   svcadmin disable network/smtp:sendmail

   ---