システム |
|---|
| ||||||||||
|
|
Version 5.1 |
||||||||||||||||||||||||||||||||
|
|
電子メールアドレスはいずれも、ドメイン名とローカル部の2 つの部分で構成されています。つま り、一般には、電子メールアドレスはxxxx@yyyyy という形式で表され、ここでyyyyy がドメイン 名（受取人のメールシステムを示す一意の名前）、xxxx がローカル部（受取人のメールシステムの ユーザー名またはアカウント名） です。
メッセージの電子メールアドレスは、ルータで解析され、そのメッセージの送信先のシステムの名前 が取り出されます。このシステムの名前が電子メールのドメイン名部として使われます。また、アド レスの残りの部分は、ローカル部として扱われます。ドメイン名で示されるシステムにメッセージが 配信される場合、このローカル部の受取人に対してメッセージが送信されることになります。上記の 例では、ドメイン名はzzzz、ローカル部はxxxx@yyyyy です。
電子メールアドレスの形式については、詳しくは、RFC822、その他の関連ドキュメントを参照してく ださい。
ローカル部が複雑なアドレス（ ローカル部がドメイン名とローカル部で構成されているようなアドレ ス） の場合、そのローカル部は、"%" 記号を使って示されます（例えば、ローカル% ドメイン1% ド メイン2 の形式）。この場合、CommuniGate Pro の正規の形式は、 local%domain1%domain2@domain です。
ルータで、電子メールアドレスからドメイン名が抽出される場合、そのドメイン名とサーバー上のド
メイン名が比較されます（この設定は、［General］ ページで行えます）。比較でドメイン名が同じであると判定された場合、そのドメイン名は空白の文字列として設定されます。その後、ルータによって
ローカル部の処理が開始され、そのローカル部が再度、ドメイン名とローカル部に分割されます。
例えば、CommuniGate Pro サーバーのメインドメインの名前がstalker.com だったとします。この場
合、次の2 つのアドレスはそれぞれ、右側に示すようにローカル部とドメイン部に分割されます。
| 電子メールアドレス | ローカル部 | ドメイン部 |
|---|---|---|
| support@company.com | support | company.com |
| -- routed --> | support | |
| <@company.com:sales@example.com> | sales@example.com | company.com |
| -- routed --> | sales@example.com | |
| -- routed --> | sales | example.com |
CommuniGate Pro は、メイン（サーバー） ドメインに加えて、複数の独立したドメインをサポートし ています。
複数のドメインを使用する場合、特定のドメインに宛てられたメッセージ（またはシグナル） が正常 に処理されることが必要ですが、そのためにはグローバルDNS システムを使用しなければなりませ ん。
例1: サーバー（example.com） にexample.com とparteners-example.com という2 つのドメインがあっ たとします。この場合、両方のドメインについてDNS MX レコードを作成し、またMX レコードがそ れぞれサーバー（example.com） を指すように設定しなければなりません。
例2: サーバー（example.com） をクライアントシステムのリモートPOP メールホストリレーとして 使用するとします。クライアントは3 つで、ドメイン名はそれぞれclient1.com、client2.com、 client3.com です。ここで、ルータを使って、ドメインclient1.com に宛てられたメッセージがすべて 統合ドメインワイドアカウントであるclient1 にルートされるようにしたかったとします。また、ド メインclient1.com へのメッセージがサーバー（example.com） にもルートされるようにします。この 場合、DNS システムにclient1.com のMX レコードを作成し、そのレコードがサーバー（example.com） を指すようにしなければなりません。
ルータで電子メールアドレスが解析され、その結果、抽出されたドメイン名がサーバーのメインドメ インの名前とは異なっていた場合、ルータにより、ルーティングテーブルのルーティングレコードが チェックされます。
ルーティングテーブルの内容は、定義と変更が可能です。定義や変更を行いたい場合、WebAdmin イ ンターフェイスの［Settings］ セクションの［Router］ ページを開きます。
ルーティングテーブルは複数の行で構成され、各行がそれぞれ独立したルーティングレコードです。 ルーティングレコードは左側の部分と右側の部分に分かれ、両者を等号（=） でつなぎます。右側の部 分には、セミコロン（;） を付加し、その右にコメントを入力できます。また、行の先頭にセミコロ ンを入力し、その右にコメントを入力することもできます。
処理ではまず、ルータに分析後のアドレス（つまりドメイン部とローカル部に分割されたアドレス） が送られます。その後、ルータによりルーティングテーブルのレコードが上から下までスキャンされ ます。ここで該当するレコードが見つかれば必要な処理が実行され（下記を参照）、その後、修正さ れたアドレスが再度、ルータによって処理されます。
ルーティングレコードにはリレーモード接頭辞を指定できます。リレーモード接頭辞としては、 Relay: （R: と簡略化可能）、NoRelay: （N: と簡略化可能）、RelayAll: の3 種類があります（詳し くは、保護 のセクションを参照）。リレーモード接頭辞を指定しなかったときには、接頭辞として Relay: が指定されていると見なされます。
また、ルーティングレコードには次の接頭辞（処理に関する接頭辞） を指定できます。ルーティングレコードの左側の部分はサンプル（見本） です。サンプルは文字列で、ワイルドカードを使用できます。
サポートされているワイルドカードは次の通りです。バックスラッシュ（\） をエスケープ文字として使用できます。バックスラッシュ2 つ（\\） は、一 つのバックスラッシュとして処理されます。\* は、アステリスクとして処理されます。
単一のサンプルに指定できるワイルドカードは一つに限られます。
ルーティングレコードの右側の部分はルート（経路） です。ルートは文字列で、オプションでワイル ドカードを使用できます。
処理対象のアドレスがいずれかのサンプルと一致した場合、そのアドレスはルート（レコードルー ト） に変換されます。サンプルとルートの両方にワイルドカードを指定した場合、サンプルのワイル ドカードに相当するサブ文字列が、ルートのワイルドカードの文字列として使用されます。
The backslash (\) symbol is used as an escape symbol: \\ is processed as a single backslash symbol, \* is processed as an asterisk symbol, etc.
Only one wildcard symbol is allowed in a Route.
ルーティングレコードの左側の部分にドメイン名を指定した場合、そのレコードについて、ドメイン レベルのルーティングが実行されます。
サーバー上で何らかのアドレスが処理され、そのアドレスのドメイン名がルーティングテーブルのい ずれかのレコードの左側の部分に定義されていた場合、レコードの左側の部分が自動的に右側の部分 に置き換えられます。
下は、ルーティングパスとしてリレーを指定するときの例です。
メッセージの宛先が複数の場合（ ドメイン名の一部が同じ）、同じようにしてルートできます。この 場合、ワイルドカードとしてアステリスクを使います。
上の方法は、ドメインのサブドメインすべてにメッセージをルートしたいときにも有用です。下は例 です。
以上はいずれもドメインレベルのルーティングレコードですが、アカウントレベルのルーティングレ コードを使って、ドメインレベルのルーティングを定義することもできます（下記を参照）。また、 ルーティングレコードとしては、統合ドメインワイドアカウントのレコードも定義でき、このレ コードもドメインレベルのルーティングレコードです。
ルーティングレコードの左側の部分には電子メールアドレスを定義することもでき、定義する場合、 電子メールアドレスを山括弧（< と>） で囲みます。これで、そのレコードは、アカウントレベルの ルーティングルールとして解釈されます。
ルータにより、電子メールアドレスの解析が行われ、その後、ルーティングテーブルのレコードがス キャンされる際、その電子メールアドレスのドメイン部と、各レコードの左側の部分のドメイン部が 比較されます。ドメイン部が同じレコードが見つかったときには、さらに、その電子メールアドレスのローカル部と、各レコードの左側の部分のローカル部が比較されます。レコードの左側の部分には アステリスクを使用することもでき、比較では、このアステリスクも考慮されます。このようにして、 電子メールアドレスのドメイン部とローカル部の両方が同じレコードが見つかった場合、ルーティン グレコードの右側の部分（エイリアス） が、その電子メールアドレスの新規のアドレスとして解釈さ れます。その後、ルータにより再度、その新規のアドレスの解析と処理が行われます。
注意: ルータによる解析の際、サーバーのメインドメインの名前は、その場で空白の文字列に置き換 えられます。そのため、アカウントレベルのルーティングレコードの場合、左側の部分にはメインド メインの名前を指定しないようにします。
以下、例を使って説明します。いずれの例でも、mycompany.com はサーバーのメインドメイン名です。
アカウントレベルのレコードの右側には、電子メールアドレスを指定することもできます。
アカウントレベルのレコードの左側の部分では、そのローカル部にワイルドカードとしてアステリス ク（*） を使用できます。また、アステリスクは右側の部分にも定義でき、その場合、アステリスクは 任意の場所に置くことができます。右側に定義したときには、左側のアステリスクの内容が右側のア ステリスクで使われます。
ルータエイリアスレコードを使って、サーバーのセカンダリドメインに向けられたメッセー ジをリルートすることもできます。
なお、アカウントレベルのルーティングレコードは、ほとんどのケースでは、とくに使用する必要は ありません。例えば、メインドメインの場合、そのアカウントにエイリアスを作成することで同様 の操作が行えます。また、ローカルドメインのアカウントに宛てられたメッセージを外部のアドレス にリルートする場合、フォワーダを利用できます。
一方、特定のアカウントに向けられたメッセージを別個に処理したい場合、アカウントレベルのレ コード（エイリアス） が必要です。例えば、ドメインのアカウントのうち、いずれかのアカウントに 向けられたメッセージはメインドメイン（または別のシステム） の特定のアカウントにルートされる ようにし、それ以外のアカウント宛のメッセージはすべて別のメールホストや統合アカウントにルー トしたい、といったケースもあります。
アカウントレベルのレコードの左側の部分が電子メールアドレスの場合、アステリスクは正規のアカ ウント名のローカル部（つまり@ の前の部分） でのみ使用できます。
左側の電子メールアドレスの部分でワイルドカード（アステリスク） を使うことにより、CommuniGate Pro のいずれか一つのドメインの中で数のドメイン（仮想ドメイン） をサポートできます。この場合、 一意の「アドレススペース（アクセスを付加した電子メールアドレス）」がそれぞれドメイン（例えば 下記のclient5.com） を表します。
上のルーティングは、ドメインのアカウントは1 つか2 つしか必要ないが、ドメインは多数ほしいと いうときに利用できます。つまり、CommuniGate Pro の正規のドメインを多数作成する必要はありません。
アカウントレベルのレコードでは、左側のアドレスのドメイン部にワイルドカード（*） を定義する ことができます。このレコードは、処理（ルーティング） 対象のアドレスのうち、ローカルドメイン （CommuniGate Pro サーバーまたはCommuniGate Pro クラスタ上に作成されたドメイン） が含まれて いるアドレスに適用されます。右側にはアドレス（ ローカル部） を指定し、そのアドレスのドメイン としては左側のアドレスのドメイン（ローカルドメイン） が使われます。
右側にドメイン部を指定した場合、そのドメインにアドレスがルートされます。
また、左側のアドレスのロカール部にワイルドカードを指定することもできます（通常のアカウント レベルのレコードと同じです）。ワイルドカードに一致した文字列は、右側のアドレスで使用されま す。
電子メールメッセージのアドレスのドメイン部がNULL であるか、またはドメイン部が空白でローカ ル部がNULL の場合、そのメッセージは「ブラックホール」モジュール（内部の仮想のモジュール） に送られます。
「ブラックホール」に送られたメッセージには「配信済み」というマークが付けられ、以後は処理は 行われません。したがって、「ブラックホール」アドレス、つまりローカル部またはドメインが NULL のアドレスを利用することで、そのアドレスに送信されたメッセージをすべて廃棄することが できます。また、アドレスMAILER-DAEMON はすべて自動的にNULL にリルートされます。
アドレスのドメイン部がERROR の場合、またはドメイン部が空白でローカル部がERROR の場合、そのアドレスは拒否され、したがって配信処理は行われません。また、「ブラックリストアドレス （Blacklisted Address）」エラーが出力されます。
アドレスのドメイン部がBlackListed の場合、または、ドメイン部が空白でローカル部が BlackListed の場合、そのアドレスは拒否され、したがって配信処理は行われません。また、「ブ ラックリストアドレス（Blacklisted Address）」エラーが出力されます。詳しくは、SMTP モジュールの説明を参照してください。
ドメイン部が空白で、かつローカル部がspamtrap の場合、ルーティングは行われません。この種 のアドレスはすべて、ERROR （エラー） アドレスとして処理されます。ただし、SMTP モジュールで は、別の方法で処理されます。この処理については、詳しくはを保護のセクションを参照してくださ い。
ドメイン部が接尾辞.here で終わる場合、この.here は自動的に削除され、残りの部分が CommuniGate Pro のローカルドメインの名前として使われます。この接尾辞を使うことで、ルーティ ングループを回避できます。
If the domain name part ends with the symbols .here, this suffix is removed, and the remaining part of the domain name is used as the name of a local CommuniGate Pro Domain. This suffix allows you to avoid routing loops in certain situations.
ルーティングレコードのスキャンの際、ドメイン部に接尾辞.via が付加されているレコードがある かどうかチェックされます。あった場合、接尾辞.via が削除され、残りのドメイン名がターゲット のホスト名として使用されます。また、アドレスのローカル部がアドレスとして使われ、そのアドレ スがターゲットのホストに渡されます。ここでアドレスは、処理がシグナル処理のときにはSIPモ ジュールに、処理がメール転送/ アクセスのときにはSMTPモジュールにルートされます。
注意: 接尾辞.via があるときには、アドレスのドメイン部が削除され、残りのアドレス（ローカル 部） だけがホストにリレーされます。例えば、ドメイン部がsales.stalker.com の場合、アドレス <user@sales.stalker.com> はアドレス<user> としてホストsales.stalker.com にリレーされます。サー バーによっては、ドメインのないアドレスを受け付けないものもあり、その場合、問題が生じます。 この問題は、接尾辞.via を付加しないという方法で回避できます（次の例を参照）。
注意: 上記で、host.com.via の代わりにhost.com と指定することもできます（他にhost.com を定義したレコードがあるときは除きます）。ただし、host.com と指定した場合、 user@client1.com 宛てのメールは、user%client1.com@host.com というアドレスでhost.com に送られます。一方、接尾辞.via を使ったときには、アドレスはリレーモジュールにルートされる と同時に、リレーモジュールによってアドレスのローカル部だけがリモートホスト（host.com） に送 信されます。
| 接尾辞.via がないときのアドレスの処理 | ||
|---|---|---|
| user @ client1.host | ルータにより次のように変換 | user%client1.host @ relay |
| user%client1.host @ relay | ルータにより次のように変換 | user%client1.host @ host.com |
| user%client1.host @ host.com | ルータの処理なし | host.comの定義なし |
| user%client1.host @ host.com | ルータの処理あり | SIP/SMTPホストhost.com user%client1.host@host.comとして送信 |
| 接尾辞.via があるときのアドレスの処理 | ||
| user @ client1.host | ルータにより次のように変換 | user%client1.host @ relay |
| user%client1.host @ relay | ルータにより次のように変換 | user%client1.host @ host.com.via |
| user%client1.host @ host.com.via | ルータの処理あり | ホストhost.com user@client1.hostして送信 |
レコードのアドレスのドメイン部に接尾辞.via がある場合、その.via が削除され、その後、ドメ イン名の右端の部分がチェックされます。この右端の部分が数値の場合、その数値の前にあるポート 番号区切り記号（.） がコロン（:） に変更されます（下記を参照）。
host.domain.26.via --> host.domain:26 上のようにドメイン名にコロンがあるときには、SIP モジュールとSMTP モジュールにより次のよう な処理が実行されます。また、ルータによってアドレスのドメイン部が接尾辞.relay で終わっているかどうかがチェック されます。この接尾辞があれば、削除され、残りのドメイン名がターゲットのホスト名として使われ ます（ この処理は、ポート番号区切り記号がコロンに変更された後に行われます）。その後、このド メイン名（ポート番号区切り記号とポート番号の削除後のドメイン名） とローカル部が@ 記号で結 合されます。
Many Signals (especially phone calls) should be handled with the "stock" or custom Real-Time Applications. To Route a Signal to an Application you need to specify the Application name and, separated with the hash (#) symbol, the name of the Account that will be used to run the application:
You can specify the application parameters by adding them after the application name, enclosed into the { and } brackets and separated with the comma (,) symbol.
The wildcards in the right part of a Router record are substituted before any processing begins, so you can use the wildcard value as the application parameter.
アドレスのドメイン部がtelnum （電話番号） の場合、そのアドレスのロカール部はE.164 電話番号 として処理されます。
ルータによる処理では、まず次の処理が実行され、その結果をもとにルーティングテーブルの処理や 必要なルーティング処理が実行されます。電話番号が上記のいずれの処理でもリルートされない場合、その電話番号は通常のアドレスとして処 理されます。
ENUM ドメインは、上記のオプションで作成できます。作成するには、空白のフィールドにENUM ドメインの名前を入力し、［Update］ ボタンをクリックします。削除したい場合、フィールドの名前 を削除し、［Update］ ボタンをクリックします。ENUM ドメインは、定義してある順番で使用されま す。
PSTN と電話番号のルーティングについては、詳しくはPSTNのセクションを参照してください。
ルーティングテーブルにはIP アドレスを定義することもできます。ルーティングテーブルのレコード に対するスキャンがすべて終わると、ルータにより、読み込まれたドメイン名がIP アドレスでないか どうかがチェックされます。ドメイン名がIP アドレスであり、そのIP アドレスが角括弧（[ と]） で 囲まれていなかったときには、自動的に角括弧が付加されます。例えば、user@10.34.45.67 は、 user@[10.34.45.67] に変換されます。したがって、ルーティングテーブルにIP アドレスを指定す る場合、角カッコで囲む必要はありません。
また、ルーティングテーブルにIP アドレスが指定されていた場合、そのIP アドレスが、いずれかの セカンダリドメインの専用IP アドレスであるかどうかがチェックされます。専用IP アドレスだった ときには、そのIP アドレスは、そのドメインの名前に置き換えられます。一方、IP アドレスがメイ ンドメインのIP アドレスだった場合、ドメイン部に空白の文字列が挿入され、その後、アドレスの ローカル部の解析が実行されます。この処理が完了すると、次の処理が開始されます。
ローカルドメインにIP アドレスが割り当てられていない場合、ドメイン名[10.34.45.67] は10.34.45.67.default_port.viaとして処理されます。アドレスは、SIP モジュールまたはSMTP モジュールに送られた後、モジュールでドメイン部が取り出され、そのドメイン部がリレー先のホス ト名として使用されます。
ルーティングテーブルがスキャンされ、アドレスに該当するレコードがなかった場合、または、その アドレスが特殊アドレスもしくはローカルドメインのIP アドレスのどちらでもなかった場合、ルータ により、各通信モジュールが呼び出されます。また、各モジュールにアドレスが渡されると同時にルー ティング処理要求が送られます。
各モジュールでは、渡されたアドレスがチェックされ、その結果に基づいて次のような処理が行われます。いずれかのモジュールでアドレスが修正された場合（上記の2 番目のケース）、ルータにより、そのア ドレス（処理後のアドレス） が再度チェックされ、上記の処理が繰り返されます。
いずれかのモジュールでアドレスが受け入れられた場合（上記の最後のケース）、ルータがメッセージ エンキューアコンポーネントから呼び出され、ルータにより、そのモジュールのキューにメッセージ が格納され、その後、配信されます。
If the Router is called from the シグナル component, and a module has accepted the address, the Signal Request is sent to this module for processing.
各モジュールに対しては、ルータから呼び出しが2 回、実行されます。最初の呼び出しでは、各モ ジュールに対して「明白」なアドレス（モジュール専用のアドレス） を処理するように指示が出され ます。つまり、この場合、モジュールでは、そのモジュールに対して直接向けられたアドレスが処理 されます。例えば、SMTP モジュールの場合、アドレスのうち、そのドメイン名が.smtp で終わるア ドレスが処理されます。また、LIST モジュールでは、既存のメーリングリストのアドレスが処理され ることになります。
最初の呼び出しで、いずれのモジュールでもアドレスが無視または拒否された場合、ルータから各モ ジュールに対して2 回目の呼び出しが実行され、ここで「最終処理」が求められます。つまり、例え ば、Local Delivery モジュールでは、各ローカルドメインに向けられたアドレスが処理されます。また、 SMTP モジュールの場合、その名前にピリオドが1 つ以上含まれているドメインのアドレスが処理さ れます。
上のように、特定の呼び出し順を用いず、各モジュールに対して「公平」に2 段階の呼び出しを実行 するという方法を使うことで、各モジュールで電子メールアドレスが的確に処理されるようになりま す。一方、特定の呼び出し順による1 段階の処理では、処理が的確に行われないことがあります。例 えば、アドレスがlistname@domainname （ ローカルドメインのアカウントのアドレスの形式） の 場合、まず、Local Delivery モジュールを呼び出し、その後、LIST モジュールを呼び出したときには、 このアドレスはLocal Delivery モジュールで拒否され、したがってLIST モジュールで処理されなくな ります。また、アドレスuser@accountName.local は、本来、Local Delivery モジュールで処理さ れなければならないのに、SMTP モジュールで扱われることになります。
上記の処理については、詳しくは各モジュールの説明を参照してください。
ルーティングレコードのスキャン後、ルータによりドメイン名として文字列external が定義され ているかどうかががチェックされます。見つかった場合、その文字列（external） が削除された後、ローカル部が外部プログラム（外部ヘルパー） に渡されます。
外部認証プログラムでは、渡されたアドレスを何らかの方法でルーティング処理を行います。処理 後、変更後のアドレスまたはエラーコードを返します。
外部プログラムから変更後のアドレスが返った場合、ルータでは、そのアドレスを使って後続の処理 が実行されます。
上のレコードを定義した場合、アドレス0115556666@local.domain.dom （シグナルの送信先の アドレス、local.domain.dom は任意のローカルドメイン） はtele-5556666@external にリルート され、要求が外部ヘルパープログラムに送信されます。要求の内容は、アドレスtele-5556666 の ルーティング処理です（ この処理が外部プログラムで実行されます）。
CommuniGate Pro のルータは、DNS ベースの電話番号ルーティングをサポートしています。このルー ティング処理は通常、E.164 番号に対して使用します。E.164 番号とは、＋記号、国番号、地域コー ド、ローカル番号で構成される電話番号をいいます。
ドメイン名に接尾辞.enum がある場合、ルータにより次のような処理が行われます。ルータが再起動し、見つかったマッピング文字列が新規のデスティネーションアドレスとして処理されます。
DNS 検索で"unknown host name （ホスト名不明） " エラーが返った場合、接尾辞.enum が接尾辞 .noenum に置き換えられます。その後、ルータが再起動し、変更後のアドレス（接尾辞.noenum のア ドレス） が処理されます。
CommuniGate Pro サーバーをインストールすると、次のレコードがデフォルトでルーティングテーブ ルに定義されます。
上記のデフォルトレコードはいずれも、必要に応じて修正と削除が可能です。
メールサーバーに上位ドメインが複数ある場合（例えば、server1.myorg.org、 server2.myorg.org、server3.myorg.org など） 場合、ユーザーによっては、非適格ドメイン 名（user@server1、user@server2、user@server3 など） を使うほうが便利というユーザーもいます。こ のような場合、また、とくにメールサーバー（myorg.org） の「上位レベル」のドメインの数が少な いときには、ルーティングテーブルにレコードを定義して、非適格ドメイン名の電子メールアクセス を使用できるように設定できます。レコードは、次のようになります。
server1 = server1.myorg.orgただし、メールサーバー（myorg.org） の「上位レベル」のサーバー（ ドメイン） の数がかなり多い ときには、その全部のレコードをルーティングテーブルに定義するのは困難なこともあります。そう いった場合、［Add myorg.org to Non-Qualified Domain Names］ オプションを有効にします。このオ プションが有効のときには、電子メールアドレスのドメイン部にピリオドが含まれていた場合、この オプションに指定されているメールサーバーの名前（myorg.org） が自動的に電子メールアクセス のドメイン部に追加されます（ピリオドも自動的に追加されます）。したがって、ルーティングテー ブルにレコードを定義する必要はなくなります。つまり、user@someserver は自動的に user@someserver.myorg.org に変換され、このアドレスを使って送信先のアドレスにルートされ るようになります。
注意：なお、電子メールアドレスに非適格ドメイン名を使用するのはできるだけ避けるようにしま す。上のオプションは、環境や条件により、ユーザーがどうしても、正規の適格ドメイン名の電子メールアドレスを使用できない場合に限って有効にするようにします。
上記のパネルを使って、全ドメインエイリアス、つまり、ローカルの全ドメインで有効なエイリアス を設定できます。CommuniGate Pro サーバーでメッセージが検出され、その送信先がいずれかのロー カルドメインだった場合、このパネルの設定がチェックされます。チェックで、そのメッセージのア ドレスのローカル部が、このパネルのいずれかの［ Local Address］ フィールドに入力されているロー カル部と同じだった場合、そのメッセージは［Reroute To］ フィールドに指定されているアドレスに リルートされます。
例えば、［All-Domain Aliases］ パネルで［abuse］ と［postmaster@maindomain.dom］ を入力し ておいた場合（上記を参照）、abuse@domain.dom （domain.dom は、CommuniGate Pro のドメイ ンのうちのいずれか） に送られたメッセージはすべて、postmaster@maindomain.com にリルー トされます。
注意：［All-Domain Aliases］ パネルでは、場合によってはルーティングループが生成されるので注意 が必要です。例えば、いずれかのドメインのポストマスターに宛てられたメールをすべて、 CommuniGate Pro のメインドメインのポストマスターにリルートするつもりで、［All-Domain Aliases］ パネルの左側と右側のフィールドにそれぞれ、次のように入力したとします。
フィールドではワイルドカード（*） を使用できます。
例えば、会社に10 の部門（ ドメイン） があり、それぞれに部門の専用番号（部門の内線番号） を作 成したい場合、次のように入力します。
ここで、各ドメインのアカウントのエイリアス（電話番号） が200-299 の範囲であるとします。こ の場合、いずれかの部門のユーザーは、2xx という番号を使って同じ部門（ ドメイン） のユーザー に電話をかけることができます。また、その部門のユーザーがドメインdomain1.com のユーザーに電 話をかけるときには、接頭辞91 を使います（具体的には、912xx という番号を使います)。さらに、 その部門のユーザーがドメインdomain2.com のユーザーに電話をかけたい場合には接頭辞92 を使い ます（具体的には、922xx という番号を使います)。
ダイナミッククラスタでは、クラスタワイドのルーティングテーブルが使用されます。このルーティ ングテーブルを開きたい場合、WebAdmin インターフェイスで、クラスタのメンバーの［Router］ ペー ジを開きます。ページにルーティングテーブルのリンクがありますので、このリンクをクリックする とクラスタワイドのルーティングテーブルが表示されます。このテーブルのレコードに変更を加える と、変更は、そのクラスタの全メンバーで有効になります。
クラスタワイドのルーティングテーブルは、サーバーのルーティングテーブルの拡張として扱われます。つまり、サーバーのルーティングテーブルに該当するレコードがなかった場合、クラスタワイド のルーティングテーブルのレコードがチェックされます。