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