CommuniGate Pro
Version 5.2
システム
 
 
 
ルータ

ルータ

このセクションでは、ルーティングについて説明します。なお、このセクションの説明は管理者向け です。ルーティングの設定は、基本的にはデフォルトの設定で十分です。したがって、CommuniGate Pro サーバーを別のシステムのリレーサーバーとして使用するときやドメインを複数扱いたい場合、 または高度なルーティングスキームを使用したい場合に限って、このセクションの説明をお読みください。

When the Server processes a submitted Message, it extracts the information about recipients from the message "envelope" and decides into which module queue the message should be placed, which entity the module should send the message to, and how it should address that entity. Similar operations are performed with Real-time Signals received from external sources or generated with internal components and directed to local or external entities.

Access modules (such as POP, IMAP, WebUser Interface, etc.) also deal with addresses. When a client application or program logs in, it provides a name of the Account it wants to log into. This address is processed using the same operations as ones used to process Message and Signal addresses.

The CommuniGate Pro Router component implements these routing operations. Whenever your Server gets some address, that address is processed using the Router component. This provides additional consistency to all Server components: when, for example, you create an Alias for some Account, that Alias can be used to send E-mail and Signals to that Account, and the Alias name can be used to log into that Account.

電子メールアドレスのドメイン部とローカル部

電子メールアドレスはいずれも、ドメイン名とローカル部の2 つの部分で構成されています。つまり、 一般には、電子メールアドレスはxxxx@yyyyy という形式で表され、ここでyyyyy がドメイン名(受 取人のメールシステムを示す一意の名前)、xxxx がローカル部(受取人のメールシステムのユーザー 名またはアカウント名) です。

電子メールアドレスとしては、さらに複雑な形式もあります。例えば、下記のように、パス情報が置 かれることもあります。
<@zzzz:xxxx@yyyyy> or zzzz!yyyyy!xxxx or xxxx%yyyyy@zzzz
上のような電子メールアドレスの場合、メッセージはまず、システムzzzz に送信され、続い て、そのシステムからxxxx@yyyyy (つまり、システムyyyyy のアカウントxxxx) に送られま す。

メッセージの電子メールアドレスは、ルータで解析され、そのメッセージの送信先のシステムの名前 が取り出されます。このシステムの名前が電子メールのドメイン名部として使われます。また、アド レスの残りの部分は、ローカル部として扱われます。ドメイン名で示されるシステムにメッセージが 配信される場合、このローカル部の受取人に対してメッセージが送信されることになります。上記の 例では、ドメイン名はzzzz、ローカル部はxxxx@yyyyy です。

電子メールアドレスの形式については、詳しくは、RFC822、その他の関連ドキュメントを参照してく ださい。

If a local part contains a complex address (i.e. the local part itself contains domain name(s) and a local part), the local part is presented using the '%' notation: local%domain1%domain2, so the full address in the CommuniGate Pro canonical form would be 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

複数のドメインとMX レコード

CommuniGate Pro サーバーで電子メールメッセージが受信され、そのメッセージの送信先として、 CommuniGate Pro サーバーのメインドメイン(一般設定で設定されているドメイン) だけでなく、他 のドメインも指定されている場合もあります。こういった他のドメイン宛のメッセージを正常に処理 する場合、そのドメインにメッセージが送信されるようにサーバーを設定しておかなければなりませ ん。

上記の処理は、例えば、CommuniGate Pro サーバー(mycompany.com) をクライアントシステムの「リ モートPOP」メールホストリレーサーバーとして設定することで可能です。つまり、クライアントシ ステムに複数のドメイン(client1.com、client2.com、client3.com) がある場合、CommuniGate Pro サー バーのルータを設定し、ドメインclient1.com に送信されるメッセージがすべて、統合ドメインワイド アカウント(client1) にルートされるようにします。また、ドメインclient1.com にメッセージが送信 されるときに、同時にサーバー(mycompany.com) にもメッセージがルートされるように設定します。

上記のようなインターネットメールのルーティングは、ドメインネームシステム(DNS) を使うこと で制御できます。ドメインネームシステムには、ドメイン名に関する情報を登録できます。例えば、 ドメイン名( クライアント) としてclient1.com を登録する場合、DNS にMX レコードを作成し、その レコードの内容としてサーバー(mycompany.com) を定義します。


ルーティングテーブル

ルータで電子メールアドレスが解析され、その結果、抽出されたドメイン名がサーバーのメインドメ インの名前とは異なっていた場合、ルータにより、ルーティングテーブルのルーティングレコードが チェックされます。

ルーティングテーブルの内容は、定義と変更が可能です。定義や変更を行いたい場合、WebAdmin イ ンターフェイスの[Settings] セクションの[Router] ページを開きます。

Log Level:
Add to Non-Qualified Domain Names

ルーティングテーブルは、各行がそれぞれ独立したルーティングレコードです。ルーティングレコー ドは左側の部分と右側の部分で構成され、両者を等号(=) でつなぎます。右側の部分には、セミコロ ン(;) を付加し、その右にコメントを入力できます。また、行の先頭にセミコロンを入力し、その 右にコメントを入力することもできます。

ルータでは、電子メールアドレスの( ドメイン部とローカル部で構成) 解析が完了すると、ルーティ ングテーブルのレコードを最初から最後までスキャンするという処理が実行されます。ここで、解析 後の結果に対応するレコードがあった場合、そのレコードをもとにルーティングが実行され、その結 果( ローカル部またはドメイン部もしくは両方) がルータで処理されます。処理の内容は、接頭辞を 使って定義できます(下記を参照)。

Log Level
CommuniGate Pro のルータにはログ設定があり、このログ設定はWeb ブラウザを使って変更で きます。設定には[Log] オプションを使い、ここで、ルータによってシステムログに記録され る情報の種類を指定できます。このオプションは、通常は[Major] (アドレスのルーティング) に設定しておきます。ただし、ルータに何らかの問題が発生しているようであれば、[Low-Level] または[All Info] に変更します。この場合、ルータの低レベルの情報がシステムログに格納さ れます。システムログのうち、ルータによって出力されたログにはROUTER タグが付加されま す。

Prefix

A Routing record can contain a Relay-mode prefix: Relay: (can be shorten to R:), NoRelay: (can be shorten to N:), or RelayAll:. See the Protection section for the details.
If none of these prefixes is specified, the NoRelay: prefix is assumed.

A Routing record can contain zero, one, or several of the following operation-type prefixes: These prefixes should be specified after an optional Relay-mode prefix. If none of these prefixes is specified, the Routing record is applied to addresses used in all operations.

Sample

The left part of a Routing record contains a Sample: a string with an optional wildcard.

The following wildcards are supported:
*
this wildcard matches zero or more symbols.
Example:
sta*r
This sample matches any staXXXXXXr string where XXXXXX is any substring (including an empty substring inside the star string).
(size type)
type is the substring type:
  • d - decimal digits (0 .. 9)
  • h - hexadecimal digits (0 .. 9, A .. F, a .. f)
  • L - alpha-numeric symbols (0 .. 9, A .. Z, a .. z)
  • * - any symbols

size is an optional substring length. It can be specified in the following forms:
  • nnn (where nnn a decimal number): a matched substring should have nnn symbols.
  • nnn+ : a matched substring should have nnn or more symbols.
  • nnn-mmm (where mmm a decimal number, mmm >= nnn): a matched substring should have between nnn and mmm symbols.
Example:
sta(3*)r
This sample matches any staXXXr string where XXX are any 3 symbols.
Example:
sta(4+d)r
This sample matches any staDDDDDr string where DDDDD are 4 or more decimal digits.
Example:
sta(3-5h)r
This sample matches any staHHHr string where HHH are 3,4, or 5 hexadecimal digits.

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 sample.

Route

The right part of a Routing record contains a Route: a string with an optional * wildcard.

When the Record Sample matches an address, the address is changed to the Record Route. The substring matching the Sample wildcard substitutes the Route wildcard.

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.

ドメインレベルのルーティングレコード

ルーティングレコードの左側の部分にドメイン名を指定した場合、そのレコードについて、ドメイン レベルのルーティングが実行されます。

サーバー上で何らかのアドレスが処理され、そのアドレスのドメイン名がルーティングテーブルのい ずれかのレコードの左側の部分に定義されていた場合、レコードの左側の部分が自動的に右側の部分 に置き換えられます。

例えば、次のようなルーティングレコードが定義されているとします。
hq.company.com = twisted.company.com
この場合、ドメイン名hq.company.com は、ドメインtwisted.company.com にリダイレクトされます。 つまり、ルータにより、twisted.company.com にメッセージを配信するのに必要なパス(ルーティ ングパス) が検索されます。

ルーティングパスとしては、リレー経路を指定することもできます。

下は、リレー経路の例です。
hq.company.com = hq.company.com@relay.company.com
この場合、ドメインhq.company.com に向けられたメッセージはすべてドメインrelay.company.com にリダイレクトされ、さらにrelay.company.com のマシンからドメインhq.company.com にリダイレ クトされます。

メッセージの宛先が複数の場合( ドメイン名の一部が同じ)、同じようにしてルートできます。この場 合、ワイルドカードとしてアステリスクを使います。

下は、アステリスクを使った例です。
*.old_company.com = new_company.com
この場合、メッセージのうち、その送信先のドメインの名前が.old_company.com で終わるメッ セージがすべてドメインnew_company.com にルートされます。

上の方法は、ドメインのサブドメインすべてにメッセージをルートしたいときにも有用です。

下は、サブドメインにメッセージをルートする場合の例です。
*.mycompany.com = mycompany.com
上で、mycompany.com は、サーバーのメインドメイン名です。この場合、メインドメインのサ ブドメインに宛てられたメッセージはすべて、メインドメインに送信されます。例えば、ユー ザー名@mail.mycompany.com というアドレスは、ユーザー名@mycompany.com として処理され ます。
アステリスクは、左側の部分と右側の部分の両方で使用することもできます。その場合、アステリス クは、右側の部分のアステリスクは、左側の部分のアステリスクに置き換えられます(同じ内容が使 われます)。
下は、左側と右側の両方でアステリスクを使用した例です。
*.old_company.com = *.new_company.com
上の場合、ドメインhost5.old_company.com に向けられたメッセージはドメイン host5.new_company.com にルートされます。
アステリスクは、ほとんどの場合、ドメイン名の先頭に付加して使いますが、別の任意の場所に置く こともできます。
system-*.mycompany.com = uu*.local
このルーティングレコードの場合、system-abc.mycompany.com 宛のメッセージは、ドメイン uuabc.local にルートされます。БикЮ単一のルーティングレコードで使用できるワイルドカードは1 種類に限られます。

以上はいずれもドメインレベルのルーティングレコード(ルータドメインレコード) ですが、エイリ アス(ルータエイリアスレコード) を使って、ドメインレベルのルーティングレコードを定義するこ ともできます。また、ルーティングレコードとしては、
統合ドメインワイドアカウントのレコードも 定義でき、このレコードもドメインレベルのルーティングレコードです。

アカウントレベル(エイリアス) のルーティングレコード

ルーティングレコードの左側の部分には電子メールアドレスを定義することもでき、定義する場合、 電子メールアドレスを山括弧(< と>) で囲みます。右側の部分には、その電子メールのエイリアスを 定義します。これで、そのレコード(エイリアスレコード) は、エイリアスのルーティングルールと して解釈されます。

ルータにより、電子メールアドレスの解析が行われ、その後、ルーティングテーブルのレコードがス キャンされる際、その電子メールアドレスのドメイン部と、各レコードの左側の部分のドメイン部が 比較されます。ドメイン部が同じレコードが見つかったときには、さらに、その電子メールアドレス のローカル部と、各レコードの左側の部分のローカル部が比較されます。レコードの左側の部分には アステリスクを使用することもでき、比較では、このアステリスクも勘案されます。このようにして、 電子メールアドレスのドメイン部とローカル部の両方が同じレコードが見つかった場合、ルーティン グレコードの右側の部分(エイリアス) が、その電子メールアドレスの新規のアドレスとして解釈さ れます。その後、ルータにより再度、その新規のアドレスの解析と処理が行われます。

注意:ルータによる解析の際、サーバーのメインドメインの名前は、その場で空白の文字列に置き換 えられます。そのため、ルーティングレコードの左側の部分には、メインドメインの名前は指定しな いようにします(指定すると、そのレコードは機能しません。下記の注意を参照)。

以下、例を使って説明します。いずれも、mycompany.com はサーバーのメインドメイン名です。

下は、一般的な定義の例です。
<sales> = bill
上の場合、送信先がsales@mycompany.com のメッセージはすべて、bill に送られます。つまり、bill@mycompany.com に宛てて送信されたのと同じです。
注意:イリアスレコードにエイリアスとしてローカル(アカウント) 名xxxx を指定した場合、その エイリアスの実際のアカウントxxxx をサーバー上で作成する必要はありません。また、実際のアカウ ントxxxx を作成しても、そのアカウントは使用されません。これは、エイリアスレコードを定義した ときには、実際のメッセージが、そのアカウントに格納されることはないためです。アカウントxxxx に宛てられたメッセージはすべて、そのアカウント以外の「どこか」にルートされます。
下は、右側に電子メールアドレスを定義した例です。
<sales> = Bill@thatcompany.com
この場合、sales@mycompany.com に向けられたメッセージはすべて、Bill@thatcompany.com に送 信されます。つまり、Bill@thatcompany.com が新規のアドレスとして解釈され、ここからドメイ ン名(thatcompany.com) とローカル部(Bill) が取り出されます。その後、ルータにより、 thatcompany.com へのルートが検索されます。

エイリアスレコードの左側の部分では、そのローカル部にワイルドカードとしてアステリスク(*) を 使用できます。また、アステリスクは右側の部分にも定義でき、その場合、アステリスクは任意の場 所に置くことができます。右側に定義したときには、左側のアステリスクの内容が右側のアステリス クで使われます。

下は、左側と右側の両方でアステリスクを定義した例です
<dept-*> = postmaster@*-dept.mycompany.com
上の場合、dept-sales@mycompany.com に宛てられたメッセージはすべて、salesdept. mycompany.com (営業部門のメールサーバー) のポストマスターに配信されます。  ルータエイリアスレコードを使って、サーバーのセカンダリドメインに向けられたメッセージ をリルートすることもできます。

下は、ローカルのセカンダリドメインclient.com にメッセージをリルートするときの例です。

下も同様の例です。
<sales@client.com> = Bill@client.com
この場合、sales@client.com 宛のメッセージはいずれも、Bill@client.com に送信されます。
下も同様の例です。
<sales@client.com> = Bill
この場合、sales@client.com に向けられたメッセージはすべて、Bill@mycompany.com ( メインド メインのアカウントBill) に送信されます。

なお、ルータエイリアスレコードは、ほとんどの場合、使用する必要はありません。例えば、メイン ドメインの場合、そのアカウントにアカウントのエイリアスを作成することで同様の操作が行えます。 また、ローカルドメインのアカウントに宛てられたメッセージを外部のアドレスにリルートする場合、フォワーダ を利用できます。

ただし、フォリンシステムのアカウントにメッセージをルートするようなときには、エイリアスレコー ドが必要になります。例えば、いずれかのドメインに向けられたメッセージをすべてメールホストや 統合アカウントにルートする必要があるが、そのドメインのアカウントのうち、特定のアカウントに 向けられたメッセージは、現在のサーバー(または別のシステム) にルートされるようにしたい、と いったケースもあります。

下は、上記のケースの例です。
Mail:<sales@client1.com> = sales-client1
Mail:client1.com = new.client1.com

上の場合、ドメインclient1.com のアカウントsales に向けられたメッセージはすべて、現在の サーバーのメインドメインのアカウントsales-client1 に送られます。一方、それ以外のアカウ ントに向けられたメッセージはいずれも、システムnew.client1.com に配信されます。

エイリアスレコードの左側の部分が電子メールアドレスの場合、アステリスクは正規のアカウント名 のローカル部(つまり、@ の前の部分) でのみ使用できます。

左側が電子メールアドレスのときには、ワイルドカード(アステリスク) を使って、ドメインの一意 の「アドレススペース」を作成し、CommuniGate Pro のいずれかドメインの中で複数のドメイン(仮 想ドメイン) をサポートすることもできます。

下は、上記の場合の例です。
<*@client5.com> = cl5-*
<*@client7.com> = cl7-*

この場合、アドレスsales@client5.com 宛のメッセージは、メインドメインのアカウントcl5- sales に送信されます。また、info@client5.com 宛のメッセージは、メインドメインのアカウント cl5-info に送られます。一方、sales@client7.com 宛のメッセージは、メインドメインのアカウン トcl7-sales に送信されます。

上の方法は、とくにドメインのアカウント数が1 つか2 つと少なく、そのためCommuniGate Pro の正規のドメインを作成する必要がなく、また作成したくないときに有効です。

All-Local Routing Records

Account-level records can use wildcard symbol (*) as the domain part. This records are applied to the addresses that contain any local Domain (i.e. a Domain created on this CommuniGate Pro Server or Cluster). The right-side address of such record specifies an address in the same local Domain.

Example:
<abuse@*> = postmaster
This record reroutes an abuse@domainX.dom address into postmaster@domainX.dom for all domainX.dom Domains created in your CommuniGate Pro system.

If the right-side address contains a domain part, the address is routed to that domain.

Example:
<abuse@*> = postmaster@somedomain.com
This record reroutes abuse@domainX.dom addresses into the postmaster%somedomain.com@domainX.dom addresses for all domainX.dom Domains created in your CommuniGate Pro system. Then the postmaster%somedomain.com@domainX.dom addresses are rerouted to the postmaster@somedomain.com address.

The local part of the left-side address can contain a wildcard (as in regular account-level records). The string matching this wildcard symbol can be used in the right-side address.

Example:
<+*@*> = 011*
This record reroutes the +490088899@domainX.dom address into the 011490088899@domainX.dom address for all domainX.dom Domains created in your CommuniGate Pro system.

特殊アドレス

アドレスのドメイン部がNULL、または、ドメイン部が空白でローカル部がNULL の場合、そのアド レスは「配信済み(delivered)」と解釈され、したがって、その後の処理は行われません。つまり、ロー カル名をNULL ( ドメイン名なし)、またはドメイン名をNULL にすることで、そのアドレスを「ブ ラックホール」アドレスとして扱うことができます。結果的に、このブラックホールアドレスに向け られたメールはすべて廃棄されます。なお、アドレスMAILER-DAEMON は、自動的にNULL にリルー トされます。

下は、例です。
bad.company.com = null
<junk> = null

上記の行をルーティングテーブルに定義しておいた場合、ドメインbad.company.com に向けられ たメールはすべて廃棄されます。また、junk ( メインドメインのアドレス) 宛のメールもすべて 廃棄されます。

アドレスのドメイン部がERROR の場合、または、ドメイン部が空白でローカル部がERROR の場合、 そのアドレスは拒否され、したがって配信処理は行われません。また、「ブラックリストアドレス (Blacklisted Address)」エラーが出力されます。

下は、例です。
bad.company.com = error
<junk> = error

上の行をルーティングテーブルに記述しておいた場合、ドメインbad.company.com に向けられた メール、また、junk ( メインドメインのアドレス) に向けられたメールはすべて拒否されます。

アドレスのドメイン部がBlackListed の場合、または、ドメイン部が空白でローカル部が BlackListed の場合、そのアドレスは拒否され、したがって配信処理は行われません。また、「ブ ラックリストアドレス(Blacklisted Address)」エラーが出力されます。詳しくは、SMTP モジュール の 説明を参照してください。

ドメイン部が空白でローカル部がタイムスタンプの場合、ルーティングは実行されません。この場合、 アドレスはERROR アドレスとして拒否されます。ただし、SMTP モジュールにより特殊な方法で処理 されます。

ドメイン部が接尾辞.hereで終わる場合、この.hereは自動的に削除され、残りの部分がCommuniGate Pro のローカルドメインの名前として使われます。この接尾辞を使うことで、ルーティングループを 回避することができます。

下は、例です。
<(1-4d)@*> = incomplete
With these records entered, dialing a 1-,2-, or 3-digit numbers will return the "Address Incomplete" error code to the client, forcing it to wait for additional input from the user.

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.

下は、例です。
dept1.xyz.com = dept1.xyz.com.here
dept2.xyz.com = dept2.xyz.com.here
*.xyz.com = *.abc.com

上の場合、ドメインxyz.com の各サブドメインに宛てられたメールはすべて、ドメインabc.com の各サブドメインにリルートされます。一方、dept1.xyz.com とdept2.xyz.com の2 つのサブドメ インに宛てられたメールは、CommuniGate Pro のローカルドメインであるdept1.xyz.com と dept2.xyz.com に送られます。

Explicit Routing via Remote Systems

After all Routing Table records are applied, the Router checks if the domain name part ends with the .via suffix. The suffix is removed, and the domain name is used as the target host name, and the local part of the address is used as the address to pass to that host. The address is routed to the SIP module for Signal operation, or to the SMTP module for E-mail transfer and access operations.

Example:
The Server Main Domain name is company.com.
E-Mails and Signals sent to the sales.company.com Domain should be relayed to a separate sales.company.com server, while addresses in all other subdomains of the company.com domain should be processed as addresses in the Main Domain, i.e. user@subdomain.company.com addresses should be processed as user@company.com addresses.
You can implement this routing using the following records:
sales.company.com = sales.company.com.via ; explicitly relay to a remote host
*.company.com = company.com ; all other subdomains are rerouted

You can also specify this routing using IP addresses:
sales.company.com = [192.0.0.1] ; explicitly relay to the IP address
*.company.com = company.com ; all other subdomains are rerouted

Note: addresses in the sales.company.com domain will be relayed with the domain part removed, i.e. the address <user@sales.company.com> will be relayed to sales.company.com host as <user>.
This may cause troubles if the sales.company.com server does not accept addresses without domains. See the next sample for a possible solution.

Example:
E-Mails and Signals sent to the client1.com, client2, and client3.com domains should be sent to the site host.com.
You can implement this routing using the following records:
client1.com = client1.com@host.com.via
client2.com = client2.com@host.com.via
client3.com = client3.com@host.com.via

or, in a more flexible way:
client1.com = client1.com@relay
client2.com = client2.com@relay
client3.com = client3.com@relay
relay = host.com.via

Note: You can specify just host.com instead of host.com.via here (given there is no other router record for host.com), but in this case mail to user@client1.com will be sent to the host.com as user%client1.com@host.com. By specifying the .via suffix you not only tell the Router to route the address to a relaying module, but you also force that module to send only the local part of the address to the remote server.

Address Processing without the .via suffix
user @ client1.hostRouter converts touser%client1.host @ relay
user%client1.host @ relayRouter converts touser%client1.host @ host.com
user%client1.host @ host.comRouter stopsno rule for host.com
user%client1.host @ host.comRouter acceptsfor SIP/SMTP host.com host
as user%client1.host@host.com
 
Address Processing with the .via suffix
user @ client1.hostRouter converts touser%client1.host @ relay
user%client1.host @ relayRouter converts touser%client1.host @ host.com.via
user%client1.host @ host.com.viaRouter acceptsfor host.com
as user@client1.host

If the domain part of the address contains the .via suffix, the module checks the last domain name part after removing this suffix. If that part is a number, the dot (.) symbol separating this part is changed to the colon (:) symbol:

host.domain.26.via --> host.domain:26 When the domain name contains a colon symbol, the SIP and SMTP modules:

The Router also checks if the domain part of the address ends with the .relay suffix. This suffix is removed and the resulting domain name is used as the target host name (after changing the optional port name separator to the colon symbol).
This domain name (after removal of the optional port name and its separator) is added to the local name, using the @ symbol as the separator.

Example:
The Server Main Domain is company.com.
E-mails and Signals for the xxxx.department.company.com domains (where xxxx can be sales, marketing, etc.) should be sent to separate servers, according to their DNS records, while addresses in all other subdomains of company.com should be processed as addresses in the Main Domain, i.e. user@subdomain.company.com addresses should be processed as user@company.com addresses.
You can implement this routing using the following records:
*.sales.company.com = *.sales.company.com.relay ; explicitly relay outside
*.company.com = company.com ; all other subdomains are rerouted

Routing to Real-Time Applications

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:

The following record routes Signals sent to the someName@someDomain address to the application myProgram started on behalf of the user@domain Account:
<someName@someDomain> = myProgram#user@domain

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 following record routes Signals sent to the someName@someDomain address to the application myProgram started on behalf of the user@domain Account. The program is started with 2 parameters - "mixer" and "fast":
<someName@someDomain> = myProgram{mixer,fast}#user@domain

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.

The following record routes Signals sent to the +(20d)@someDomain addresses to the application myProgram started on behalf of the user@domain Account. The program is started with a parameter. The parameter is the catenation of the string num= and the wildcard value - the phone number without the leading + symbol:
<+(20d)@someDomain> = myProgram{num=*}#user@domain

Phone Number Routing

If the domain part of an address is telnum, the address local part is processed as a E.164 phone number.

The following steps are taken by the Router before it applies its Routing Table(s) and other routing methods:

If the phone number is not rerouted by any of the above methods, the Router processes it as a regular address.

Phone Number ENUM Domains

To add a ENUM domain, enter its name into the empty field, and click the Update button.
To remove a ENUM domain, remove its name from the field and click the Update button.
Domains are used in the specified order.

See the PSTN section to learn more about PSTN and telephone number routing.


Routing by IP Addresses

After all Routing Table records are applied, the Router checks if the domain name is actually an IP address. If the IP-address domain name is not enclosed into the square brackets, the Router encloses it: user@10.34.45.67 is converted into user@[10.34.45.67]. This allows you to specify Routing Table records for IP addresses assuming that the address is always enclosed into square brackets.

For IP addresses enclosed in square brackets, the Router checks if the IP address is assigned to one of this Server Domains. If a Domain is found, the IP address is substituted with that Domain name. If the IP address is the IP address of the Server Main Domain, an empty string is placed into the domain name part, and the Router makes the next iteration after parsing the local name part of the address.

If an IP address is not assigned to a local Domain, the Router processes the [10.34.45.67] domain name as the 10.34.45.67.default_port.via name:
the Router sends the address to the SIP or SMTP module, cutting off the domain part and using it as the host name to relay to.


各モジュールを介したルーティング

ルーティングテーブルがスキャンされ、アドレスに該当するレコードがなかった場合、または、その アドレスが特殊アドレスもしくはローカルドメインのIP アドレスのどちらでもなかった場合、ルータ により、各通信モジュールが呼び出されます。また、各モジュールにアドレスが渡されると同時にルー ティング処理要求が送られます。

各モジュールでは、渡されたアドレスがチェックされ、その結果に基づいて次のような処理が行われ ます。

いずれかのモジュールでアドレスが修正された場合(上記の2 番目のケース)、ルータにより、そのア ドレス(処理後のアドレス) が再度チェックされ、上記の処理が繰り返されます。

いずれかのモジュールでアドレスが受け入れられた場合(上記の最後のケース)、ルータがメッセージ エンキューアンポーネントから呼び出され、ルータにより、そのモジュールのキューにメッセージ が格納され、その後、配信されます。

If the Router is called from the Signal 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 Helper Routing

After all Routing Table records are applied, the Router checks if the domain name is the external string. In this case, the domain part is cut off, and the local part is passed to the External Authenticator program.

The external program can use any method to process the supplied address, and it should return a modified address or an error code.

If a modified address is returned, the Router makes the next iteration with this new address.

Example:
Signals to addresses starting with 011 in any local Domain should be routed using an external Helper program.
You can implement this routing using the following record:
NoRelay:Signal:<011*@*> = tele-*@external ; route using an external program

If a Signal is sent to 0115556666@local.domain.dom, where local.domain.dom is a local Domain, the address will be rerouted to tele-5556666@external and the External Helper will receive a request to route the tele-5556666 address.


ENUM Routing

The Router supports DNS-based routing for telephone numbers. This method is usually applied to E.164 numbers - telephone numbers starting with the plus symbol followed with the country code, area code, and the local number.

If the domain name has the .enum suffix, then the Router:

The Router restarts, processing the found mapping string as the new destination address.

If the DNS search returns the "unknown host name" error, the .enum domain name suffix is replaced with the .noenum suffix, and the Router restarts to process the modified address.

Example:
Router records:
<+(d)@*> = +*@telnum ; direct +number to e164 "telnum" domain
telnum = e164.arpa.enum ; direct +number to e164.arpa
e164.arpa.noenum = pstn
<+44*@pstn> = gatewaycaller{+44*}#pbx
pstn = main.office.dom

A sample address +14153837164@some.local.domain will be processed using the following steps:

  • The first Router record converts this address to +14153837164@telnum
  • The second Router record converts this address to +14153837164@e164.arpa.enum
  • The Router looks for a DNS NAPTR record 4.6.1.7.3.8.3.5.1.4.1.e164.arpa
  • The resulting record sip:pbx@communigate.com is found, the sip: prefix is removed, and the Router restarts to process the pbx@communigate.com address

A sample address +14155551212@some.local.domain will be processed using the following steps:

  • The first Router record converts this address to +14155551212@telnum
  • The second Router record converts this address to +14155551212@e164.arpa.enum
  • The Router looks for a DNS NAPTR record 2.1.2.1.5.5.5.5.1.4.1.e164.arpa
  • There is no NAPTR record for this domain name, so the address is converted to +14155551212@e164.arpa.noenum and the Router restarts to process this address
  • The third Router record converts the address into +14155551212@pstn and the Router restarts to process this address
  • The fourth Router record directs all calls to the +44 country code to the local gatewaycaller PBX application, but this record does not match the +14155551212@pstn address
  • The fifth Router record redirects this address to +14155551212@main.office.dom so the Signal is relayed to the main.office.dom server.

デフォルトレコード

CommuniGate Pro サーバーをインストールすると、デフォルトで次のレコードがルーティングテーブ ルに置かれます。

<root> = postmaster
このレコードがある場合、ユーザー"root" 宛のメールがすべてポストマスターアカウントにリ ルートされます。Unix システムでは、多くの場合、あらかじめロギングユーティリティのレポー トがすべて、ユーザー"root" に送信されるように設定されています。このレコードはとくに、 こういったシステムで有用です。
localhost =
多くのシステムでは、ドメイン名"localhost" は、そのコンピュータのローカルIP アドレスのシ ノニムとして設定されています。また、メールプログラムによっては、"localhost" がドメイン名 として使われることがあります。このレコードが定義されている場合、ドメイン"localhost" の アドレスがサーバーのメインドメインのアドレスにリルートされます。したがって、上記のようなシステムやメールプログラムで、シノニムやドメイン名をメインドメイン名に置き換えた いときに有用です。
mailhost =
メールプログラムの中には、"mailhost" 名がローカルメールサーバーのドメイン名として使われ るものもあります。このレコードがある場合、"mailhost" 名がサーバーのメインドメインのアカ ウント名に置き換えられます。
<blacklist-admin*@blacklisted> = postmaster
このレコードがある場合、ブラックリストホスト(ブラックリストに登録されているホスト) が「ホワイトホール」ホスト(ブラックリストから除外したホスト) として処理されます。
<7(2d)@*> = pbx{*}#pbx
This record redirects all Signals (calls) sent to 7nn addresses in any local Domain to the pbx Account in the same Domain.
This Router record is needed to implement certain functions of the stock PBX Center application.
<8(3d)@*> = pickup{*}#pbx
This record redirects all Signals (calls) sent to 8nnn addresses in any local Domain to the pbx Account in the same Domain, starting the pickup application. The application then routes the nnn@callerDomain address and "picks up" an incoming call pending for that Account.
See the PBX Services section for the details.
<+(8-20d)@*> = +*@telnum
This record redirects all +nnnn...nn addresses in any local Domain to the fictitious telnum domain.
Signal:telnum = pstn
This record redirects all Signals (calls) sent to the fictitious domain telnum to the fictitious pstn domain.
Signal:<*@pstn> = gatewaycaller{*}#pbx
This record redirects all Signals (calls) sent to the fictitious pstn domain to the gatewaycaller application started on behalf of the pbx Account in the Main Domain.
The phone number (the local part of the address in the pstn domain) is passed to the application as a parameter.
Signal:<911@*> = emergency@localhost
This record redirects all Signals (calls) sent to the 911 addresses in any local Domain to the emergency name in the localhost domain (this name is usually Routed to the Main Domain).
Signal:<112@*> = emergency@localhost
This record redirects all Signals (calls) sent to the 112 addresses in any local Domain to the emergency name in the localhost domain (this name is usually Routed to the Main Domain).
Signal:<emergency> = emergency#pbx
This record redirects all Signals (calls) sent to the emergency addresses in the Main Domain to the emergency application started on behalf of the pbx Account in the Main Domain.
Signal:<(7d)@*> = localAreaCall{*}#pbx@localhost
This record redirects all Signals (calls) sent to 7-digit numbers in each local Domain to the localAreaCall application started on behalf of the pbx Account in the Main Domain.
The phone number (the local part of the address) is passed to the application as a parameter.

上記のデフォルトレコードはいずれも、必要に応じて修正と削除が可能です。


非適格ドメイン名の使用

メールサーバーに上位ドメインが複数ある場合(例えば、server1.myorg.org、 server2.myorg.org、server3.myorg.org など) 場合、ユーザーによっては、非適格ドメイン 名(user@server1、user@server2、user@server3 など) を使うほうが便利というユーザーもいます。こ のような場合、また、とくにメールサーバー(myorg.org) の「上位レベル」のドメインの数が少な いときには、ルーティングテーブルにレコードを定義して、非適格ドメイン名の電子メールアクセス を使用できるように設定できます。レコードは、次のようになります。

server1 = server1.myorg.org
server2 = server2.myorg.org
server3 = server3.myorg.org

ただし、メールサーバー(myorg.org) の「上位レベル」のサーバー( ドメイン) の数がかなり多い ときには、その全部のレコードをルーティングテーブルに定義するのは困難なこともあります。そう いった場合、[Add myorg.org to Non-Qualified Domain Names] オプションを有効にします。このオ プションが有効のときには、電子メールアドレスのドメイン部にピリオドが含まれていた場合、このオプションに指定されているメールサーバーの名前(myorg.org) が自動的に電子メールアクセス のドメイン部に追加されます(ピリオドも自動的に追加されます)。したがって、ルーティングテー ブルにレコードを定義する必要はなくなります。つまり、user@someserver は自動的に user@someserver.myorg.org に変換され、このアドレスを使って送信先のアドレスにルートされ るようになります。

注意:なお、電子メールアドレスに非適格ドメイン名を使用するのはできるだけ避けるようにします。 上のオプションは、環境や条件により、ユーザーがどうしても、正規の適格ドメイン名の電子メール アドレスを使用できない場合に限って有効にするようにします。


全ドメインエイリアス

All-Domain Aliases
Local NameReroute to

上記のパネルを使って、全ドメインエイリアス、つまり、ローカルの全ドメインで有効なエイリアス を設定できます。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] パネルの左側 と右側のフィールドにそれぞれ、次のように入力したとします。

postmaster -> postmaster@maindomain.dom
この場合、ルーティングループが生成され、その結果、ポストマスターとしてサーバーに接続できな くなります。いずれかのドメインのポストマスターに宛てられたメールをメインドメインのポストマ スターにリルートしたい場合、次のように入力しなければなりません。
postmaster -> anyname@postmaster.local
または、[
Direct Mailbox Addressing] オプションを有効に設定しているときには、次のように入力しま す。
postmaster -> mailboxName#postmaster

You can use wildcard (*) symbols in these fields.

For example, you may want to create a "dial plan" for your organization that has 10 different departments, each served with its own Domain:

All-Domain Aliases
Local NameReroute to

If Accounts in each Domain have aliases in the 200-299 range, then the users can call other users within the same Domain by dialing the 2xx number.
They dial the 91 prefix (a 912xx number) to reach users in the domain1.com Domain.
They will use the 92 prefix to reach users in the domain2.com Domain, etc.


クラスタワイドルーティングテーブル

ダイナミッククラスタでは、クラスタワイドのルーティングテーブルが使用されます。このルーティ ングテーブルを開きたい場合、WebAdmin インターフェイスで、クラスタのメンバーの[Router] ペー ジを開きます。ページにルーティングテーブルのリンクがありますので、このリンクをクリックする とクラスタワイドのルーティングテーブルが表示されます。このテーブルのレコードに変更を加える と、変更は、そのクラスタの全メンバーで有効になります。

クラスタワイドのルーティングテーブルは、サーバーのルーティングテーブルの拡張として扱われま す。つまり、サーバーのルーティングテーブルに該当するレコードがなかった場合、クラスタワイド のルーティングテーブルのレコードがチェックされます。


CommuniGate® Pro Guide. Copyright © 1998-2007, Stalker Software, Inc.