|
ゲートウェイについて
ゲートウェイとは、ご自分のサーバを他の機器やサーバと接続する橋渡しをするものです。FirstClassは、以下のようなゲートウェイに対応しています。
・サーバ間のゲートウェイ
・他のメールシステムへのゲートウェイ
・送信用ゲートウェイ
・受信用ゲートウェイ
ゲートウェイの設定は、管理者デスクトップの［Gateways and Services]フォルダで行います。他のシステムやハードウェアに対応しているサードパーティ製のゲートウェイは数多くありますが、このドキュメントでは、サーバ間のゲートウェイを設定する方法について説明します。他のゲートウェイ設定方法については、対応製品の説明書を参照してください。
サーバ間のゲートウェイ
サーバ間のゲートウェイによって、複数のFirstClassサーバどうしを接続したり、FirstClassサーバをインターネットサービスなどの拡張モジュールを使用している他のFirstClassサーバと接続したりすることができます。サーバ間ゲートウェイを利用すると、メール機能と会議室機能が統合され、会議室の複製、ディレクトリの同期、および複数サーバを介したメッセージ配信に対応した大規模なネットワーク環境を構築することができます。ご利用のFirstClassサーバには、サーバ間ゲートウェイ用のソフトウェアがあらかじめ組み込まれています。
サーバ間ゲートウェイを構築する一番の理由は、あるサーバのユーザと他のサーバのユーザとの間でコミュニケーションできるようにするためです。ユーザがリモートサーバに接続するには、そのリモートサーバでユーザアカウントを登録すれば可能になります。しかし、ユーザは常にローカルサーバに接続し、ローカルサーバとリモートサーバの間でメッセージがやり取りされるようにした方がはるかに効率的です。もちろん、ユーザがインターネットを利用できる場合は、直接相手の電子メールアドレスにメッセージを送信するのが最も簡単な方法です。
他の電子メールシステムへのゲートウェイ
他の電子メールシステムにゲートウェイを設定すると、ご利用のFirstClassサーバがMicrosoft Mailやcc:Mailなどの他のメールシステムに接続できるようになります。
送信用ゲートウェイ
送信用ゲートウェイを設定すると、ユーザはメッセージを送信できるようになりますが、受信することはできません。送信ゲートウェイの例としては、FAXゲートウェイ、ポケットベルゲートウェイ、プリンタゲートウェイなどがあります。
受信用ゲートウェイ
受信用ゲートウェイを利用すると、外部のシステムからメッセージを受信できるようになりますが、ユーザがそのメッセージに返信することはできません。受信用ゲートウェイの例としては、ニュースゲートウェイや気象衛星画像を受信するゲートウェイなどがあります。
会議室の複製について
ゲートウェイを利用すると、サーバ間でユーザのメールをやり取りできるだけでなく、会議室を複製できるようになります。つまり、その会議室の内容がすべて含まれた完全な複製を両方のサーバに表示させて利用できるようになります。ローカルサーバ上の会議室に投稿されたすべてのメッセージが、リモートサーバ上の会議室に複製されます。また、その逆も同様です。
 注意削除されたメッセージの同期は、複製されている会議室間では行われません。新しいメッセージと既存のメッセージだけが複製されます。したがって、ある会議室のメッセージをすべてのサーバから削除しなければならなくなった場合は、複製会議室のあるすべてのシステムの管理者に連絡して、そのメッセージを削除してもらうようにしてください。
会議室を複製するには、複製会議室を置く予定になっている全サーバのFirstClass管理者間で調整を行う必要があります。
会議室の複製の設定が完了すると、次にゲートウェイが接続した時に、ローカルの会議室のアイテムがリモートの会議室に複製されます。
リモートサーバの管理者も自サーバ上で会議室の複製の設定を行って、そのサーバ上の会議室にあるアイテムが元の会議室に複製されるようにしなければなりません。
複製ループの回避
複製ループとは、自分の会議室を他のサーバに複製すると、そこから他のサーバに複製が行われ、さらにそのサーバから自分のサーバに複製が行われてしまう状態を指します。
複製ループを設定してしまわないように注意してください。例えば、ある会議室で下図のような複製方法を設定したとします。
 この例では、東京支社で投稿されたアイテムがボストン本社に複製され、それがストックホルム支社に複製され、また東京支社に複製が戻され、それがまたボストン本社に…という具合にループが発生しています。
FirstClassサーバは、このアイテムの履歴からループを発見します。ループを発見すると、複製エラー「Type 1」を（サーバコンソールとログファイルに）記録して、そのループを停止します。前述の例では、東京支社のサーバは、ストックホルム支社からアイテムを受信した時にこのエラーを記録します。このエラーが起こったら、該当する会議室を利用している他のサイトの管理者に連絡して、この問題を解決してください例えば、東京支社とストックホルム支社を結んでいるゲートウェイからこの会議室にエイリアスを削除すれば、複製ループをなくすことができます）。
複製ループを回避するには、会議室の複製方法を図に書いてみることをお勧めします。上図のボストン本社と東京支社のように、複数のパス（宛先までの接続経路）で会議室を複製できる状態になっているサーバがないか探してください。上図のボストン本社と東京支社のサーバは、会議室を互いに直接複製することも、ストックホルム経由で間接的に複製することも可能な状態になっています。
セルフサービス複製について
多数の会議室がある自分のサーバにネットワーク上で複数の異なるサーバが接続している場合、それらにサーバには、自分のサーバにあるすべての会議室を複製する必要はない場合があるでしょう。この場合、他のサーバの管理者に、自分のサーバから必要な会議室だけを選んでもらうようにすることができます。これを、セルフサービス複製といいます。
新しい会議室を作成したり古い会議室を削除したりした場合は、必ずセルフサービス複製用の会議室を更新して、他の管理者に知らせてください。
セルフサービス会議室へのアクセスの管理
標準グループ群に属するグループの１つに、［Other Sites］というグループがあります。このグループには、リモートサーバ上のゲートウェイとユーザがすべて所属しています。このグループを利用して、ゲートウェイが１日あたりに接続できる時間を長くすることができます。また、自分のサーバにある会議室に他のサーバのユーザが参加できないようにすることもできます。
例えば、トロント支社とボストン本社が「販売報告」という会議室を複製して利用しているとします。トロント支社のFirstClass管理者は、ボストン本社のユーザがトロント支社側の「販売報告」会議室に直接参加できないようにしたいと考えています（通常の状態では、ボストン本社のユーザがメールの宛先を「販売報告,トロント支社」と指定すると、トロント支社側の会議室に投稿することができます）。トロント支社の管理者は、ボストン本社のユーザには本社サーバの「販売報告」会議室を利用してもらいたいと考えています。そこで、トロント支社の管理者は、支社サーバにある「販売報告」会議室に対して、［Other Sites］ユーザグループがアクセスできないように権限を設定します。
会議室の複製を行うと、各サーバの管理者どうしで調整を行う必要があることにご注意ください。会議室を他のサーバに複製しても、その権限までは複製されません。つまり、自分のサーバにある会議室でどのような権限を設定していたとしても、リモートサイトにある複製会議室のメッセージは、すべて自分の会議室に複製されることになります。したがって、リモートの会議室上では権限があっても、ローカルの会議室上では権限がないユーザからの投稿を受け付けたくない場合は、そのリモートサーバの管理者に連絡して、会議室の権限が両方のサーバで同じになるように設定してください。
マルチサイトメールの設定
FirstClassのマルチサイトメール機能を利用すると、多数のサーバが接続された大規模なメール配信ネットワークを構築することができます。FirstClassは、中間地点にあるすべてのサーバ間ゲートウェイ経由でどのようにメールを他のサイトに中継するかを自動的に決定します。
あるFirstClassサーバが他のサイト宛のメールを受信すると、まずその宛先サイトへのゲートウェイがあるかを確認します。もしゲートウェイがあれば、FirstClassサーバはゲートウェイにメールを配信します。もしゲートウェイがなければ、宛先のサイトのルートがあるかを確認します。ルートとは、送り先への経路上にある次のゲートウェイを示すものです。ルートがあれば、サーバはそのルートで指定されたゲートウェイにメールを転送します。
ルートを作成できるのは、最終の宛先サーバへのゲートウェイかルートを持つ他のFirstClassサーバにゲートウェイできる場合だけです。中継点となる各ゲートウェイのことをホップといいます。また、メールをルートの終点まで配信するのに必要なホップの組み合わせをパスといいます。ルートを追加するためには、まず最終目的地となるリモートサーバのシリアル番号とサイト名を知らなければなりません。この情報は、中継点となるゲートウェイの管理者から、あるいは作成中のルート先にあるサーバの管理者から教えてもらうことができます。
先ほどの会社のネットワークを例にとって検討しましょう。
 マルチサイトメールのネットワークでは、ユーザは、メールの宛先にゲートウェイを指定するのと同じ要領で、メールの宛先ルートを指定することができます。例えば、トロント支社のユーザが東京支社のユーザにメールを送信するとします。トロント支社のサーバは、そのメッセージをボストン本社のゲートウェイに送信し、ボストン本社がそのメッセージを東京支社に送信します。
また、FirstClassのディレクトリにリモート名を表示させることができます。リモート名とは、リモートサーバに登録されているユーザのディレクトリエントリです。リモート名がディレクトリで閲覧できれば、ユーザは、そのユーザ名だけをメールの宛先にすることができ、ルート名を宛先に加える必要はありません。
ルートとリモート名は、手動でFirstClassディレクトリに追加することもできますが、時間がかかる上に失敗することの多い方法です。したがって、ディレクトリの同期作業を行って、自動でディレクトリを共有するようにした方がよいでしょう。どちらの方法についても、次の項で説明いたします。
ディレクトリ同期による自動マルチサイトメール
ディレクトリ同期を行って、ネットワーク内でマルチサイトメールを自動で設定することができます。ご利用のサーバに登録されている同期を取りたいユーザ、ルート、およびゲートウェイを指定してから同期を有効にすると、指定したユーザなどが他のすべてのサーバのディレクトリに追加されます。ユーザとリモート名はリモート名として追加され、ゲートウェイとルートはルートとして追加されます。
ディレクトリの同期を行うには、FirstClassスクリプトを使用します。FirstClassスクリプトのコマンドを使用すると、サーバのディレクトリが同期元サーバからエクスポートされ、同期先のサーバにインポートされます。
ディレクトリ同期で考慮すべきこと
ご利用のネットワーク上にあるすべてのサーバで同期を有効にするにあたっては、以下の点をご検討ください。
・ご利用のネットワークの規模が大きい場合、ディレクトリ同期によって非常に大きなディレクトリが作られてしまうことがあります。数千もの名前がディレクトリに追加されると、実際に使用するのが難しくなります。
・国際電話回線など費用のかかる方法でサーバが接続を行っている場合は、完全同期にかかるコストが高くなる可能性があります。
・（登録名が2000以上ある）大きなディレクトリの場合、ディレクトリのエクスポート処理によってサーバの実行速度が低下する可能性があります。サーバがあまり活動していない時間帯にエクスポートのスケジュールを設定してください。
・（登録名が2000以上ある）大きなディレクトリを同期する場合、サーバに割り当てるメモリ容量を大きくしてください。目安としては、メモリを各セッションで1000名あたり10KB増やしてください。
・同期によってマルチサイトメールを自動設定したいが、ディレクトリの大きさは制限したいとお考えの場合は、サイトの同期を取るという方法があります。この同期によって作成されたディレクトリのリストは、リモート名を含まないため比較的小さくなります。
以上の点を考慮すると、ご利用のネットワーク上では同期を行わない方がよいと判断される場合もあるでしょう。その場合でも、手動でリモート名とルートを追加して管理すれば、リモートサーバ上のユーザにメールを送ることが可能になります。
ディレクトリ同期の種類
以下の種類のディレクトリ同期から１つを、スケジュール設定によって実行することができます。
定期完全同期処理
設定したスケジュールにしたがって、ディレクトリの完全同期を行います。
デマンド同期処理
ご利用のディレクトリにエントリが追加または削除された場合にだけ同期を行います。
手動同期処理
手動で開始した場合にだけ同期を行います。
ネットワークの構築
ディレクトリ同期を使用することに決めたら、次に構築するネットワークを検討します。ご利用になるネットワークの接続経路を例えば下図のように設計し、複製ループが起きないようにしてください。
この例は先ほどの会社のものですが、今度はディレクトリ同期を有効にしています（各サーバの横にある「D」で表しています）。
 ストックホルム支社のサーバとボストン本社のサーバには互いを直接結ぶゲートウェイがありますが、この２つのサーバのディレクトリは東京支社のサーバ経由で複製されるため、複製ループは起こりません。
手動マルチサイトメール
| ||