アカウントへのアクセス

CommuniGate Pro のアカウントのメールボックスはいずれも共有が可能です。つまり、メールボッ クスには、そのメールボックスのオーナーだけでなく、他のユーザー（アカウント） もアクセスでき ます。ただし、他のユーザーのメールボックスにアクセスする場合、そのメールボックスにアクセス する権限が、そのユーザーに付与されていなければなりません。この権限は、メールボックスのオー ナーまたは管理者が付与できます。

• 指定されたアカウント名に@ または% のいずれかの記号があった場合、サーバーでは、そのユー ザー名が正式のアカウント名であると解釈されます。正式のアカウント名とは、アカウント名 とドメインの組み合わせ、つまり、ユーザー名@ ドメイン名、または、ユーザー名% ドメイン名の 形式のアカウント名をいいます。
• カウント名に@ または% がなかったときには、その接続で使われたIP アドレスがチェックされ ます。ここで、システムがマルチホーミングの場合（ ローカルのIP アドレスが複数ある場合）、 そのIP アドレスがいずれかの専用IP アドレス（いずれかのセカンダリドメインに割り当てられ ているIP アドレス）であるかどうかがチェックされます。チェックで、接続に使用されたIP ア ドレスがいずれかのセカンダリドメインの専用アドレスだったときには、そのセカンダリドメ インの名前がアカウント名の後ろに追加され、正式のアカウント名が生成されます。一方、接 続に使用されたIP アドレスがメインドメインのIP アドレスだったときには、指定されたアカウ ントはメインドメインのアカウントとして処理されます。

下は、例です。

サーバーコンピュータのIP アドレスが2 つあり、それぞれ、192.0.0.1 と192.0.0.2 だっ たとします。
また、サーバーのメインドメインがcompany.com で、そのほか、client1.com と client2.com という2 つのセカンダリドメインがあるとします。
DNS で、company.com のA レコードの内容（IP アドレス） が192.0.0.1 だったとします。
ドメインclient1.com のA レコードの内容が192.0.0.2 （専用IP アドレス） で、ドメイン client2.com のA レコードの内容がメインドメインと同じIP アドレス（つまり、192.0.0.1） だったとします。
また、3 つのドメインにそれぞれアカウントinfo が存在します。

各ドメインのユーザーはいずれも、POP メーラーまたはIMAP メーラーを使って自分のアカウント （info） にアクセスしますが、そのメーラーの「メールサーバー」の設定はそれぞれ異なります。つ まり、最初のユーザーはメールサーバーとしてcompany.com、2 番目のユーザーはclient1.com、3 番目 のユーザーはclient2.com を指定しているとします。

最初のユーザーがメーラーでアクセスを開始すると、次のように処理が実行されます。

• メーラーにより、そのメーラーに指定されているメールサーバーの設定（company.com） が 取得され、その後、ドメインネームシステムのA レコードを使って、その名前 （company.com） がIP アドレス（192.0.0.1） にリゾルブされます。
• メーラーにより、そのIP アドレス（サーバーコンピュータの2 つのアドレスのうちの１ つ） を 使ってサーバーに接続が実行され、サーバーにユーザー名（info） が渡されます。
• サーバーでユーザー名（info） が検出され、また、その接続がサーバーのアドレス192.0.0.1 を 使って確立されたことが検出されます。
• サーバーで、　そのIP アドレス（192.0.0.1） がメインドメインのIP アドレスであることが認識さ れ、指定されたアカウント名（info） にメインドメインの名前（company.com） が付加され ます。
• 以上のようにして、サーバーで、正式のアカウント名であるinfo@company.com が取得され ます。

2 番目のユーザーがメーラーでメールをチェックすると、次のように処理が実行されます。

• メーラーにより、そのメーラーで指定されているメールサーバーの設定（client1.com） が 取得され、その後、ドメインネームシステムのA レコードを使って、その名前 （client1.com） がIP アドレス（192.0.0.2） にリゾルブされます。
• メーラーにより、そのIP アドレス（サーバーコンピュータの2 つのアドレスのうちの１ つ） を 使ってサーバーに接続が実行され、サーバーにユーザー名（info） が渡されます。
• サーバーでユーザー名（info） が検出され、また、その接続がサーバーのアドレス192.0.0.2 を 使って確立されたことが検出されます。
• サーバーで、　そのIP アドレス（192.0.0.2） がセカンダリドメインclient1.com のIP アドレス であることが認識され、指定されたアカウント名（info） に、そのセカンダリドメインの名前 （client1.com） が付加されます。
• 以上のようにして、サーバーで、正式のアカウント名であるinfo@client1.com が取得され ます。

3 番目のユーザーがメーラーでメールをチェックすると、次のように処理が実行されます。

• メーラーにより、そのメーラーで指定されているメールサーバーの設定（client2.com） が 取得され、その後、ドメインネームシステムのA レコードを使って、その名前 （client2.com） がIP アドレス（192.0.0.1） にリゾルブされます。
• メーラーにより、そのIP アドレス（サーバーコンピュータの2 つのアドレスのうちの１ つ） を 使ってサーバーに接続が実行され、サーバーにユーザー名（info） が渡されます。
• サーバーでユーザー名（info） が検出され、また、その接続がサーバーのアドレス192.0.0.1 を 使って確立されたことが検出されます。
• サーバーで、　そのIP アドレス（192.0.0.1）がメインドメインcompany.comのIP アドレスである ことが認識され、したがって、指定されたアカウント名（info） にメインドメインの名前 （company.com） が付加されます。ここで、ドメインclient2.com のA レコードの内容も同 じIP アドレス（192.0.0.1） ですが、いずれかのドメインに割り当てられるIP アドレスは１ つに 限られるため、この場合、IP アドレス192.0.0.1 は最初のドメイン、つまりメインドメイン company.com に割り当てられます。
• 以上のようにして、サーバーでは、正式のアカウント名としてinfo@company.com が取得され ますが、これは誤りです。

上の問題は、メーラーからサーバーに送信される情報が「メールサーバー」の名前でなく、IP アドレ スであることが原因です。具体的には、上の場合、メインドメインcompany.com とセカンダリドメイ ンclient2.com のIP アドレスが同じであるため、サーバーでは、どちらのドメインが接続先のドメイ ンであるか検出できず、結局、デフォルトとしてメインドメインが選択されることに原因があります。

この問題は、3 番目のユーザーがアカウント名としてinfo ではなくinfo%client2.com を使用す ることで解決できます。info%client2.com を使った場合、処理は次のようになります。

• メーラーにより、そのメーラーで指定されているメールサーバーの設定（client2.com） が 取得され、その後、ドメインネームシステムのA レコードを使って、その名前 （client2.com） がIP アドレス（192.0.0.1） にリゾルブされます。
• メーラーにより、そのIP アドレス（サーバーコンピュータの2 つのアドレスのうちの１ つ） を 使ってサーバーに接続が実行され、サーバーにユーザー名（info%client2.com） が渡され ます。
• サーバーで正式のユーザー名（info%client2.com） が検出されます。一方、IP アドレスは 無視されます。また、% が@ に変換されます。
• 最後に、サーバーで正式のアカウント名としてinfo@client2.com が取得されます。

注意: なお、上の問題は、3 番目のユーザーがWebUser インターフェイスを使ってアクセスする場合には発 生しません。この場合、サーバーでは必ず、HTTP プロトコルを使ってアクセス先のドメイン名が取 得されます。したがって、IP アドレスによるドメイン名の取得（DNS） は不要です。

注意:FTP クライアントの動作は、POP/IMAP メーラーの動作と同じです。そのため、3 番目のケー スでは、FTP クライアントのユーザーは、POP/IMAP メーラーと同じく有効なアカウント名（アカウ ント名% ドメイン名の形式） を指定する必要があります。ただし、アクセス先のドメインに専用IP ア ドレスが割り当てられている場合は、その必要はありません。

注意:MAPI Connector では必ず、有効なアカウント名が送信されます。つまり、ユーザーが@ ま たは% なしのアカウント名（ユーザー名のみ） を使用しているときでも、MAPI Connector によって 自動的に、そのアカウント名に@ 記号とサーバー名が付加されます。したがって、上記の問題は起 こりません。

• ルータでエラーが出力された場合、クライアントの認証は拒否され、同時にエラーメッセージ がクライアントアプリケーションに送信されます。この場合のエラーは、通常は「不明なユー ザー」エラーですが、ルータまたはモジュールにより、そのアドレスがルーティングされると きに発生したエラーであることもあります。
• ルータにより、そのアドレスが正常にルートされたものの、そのアドレスのルート先がLocal Delivery モジュールだったときには、クライアントの認証は拒否され、エラーメッセージがクラ イアントアプリケーションに送信されます。この処理（エラー） は、ユーザーが指定したアド レスがアカウント名ではなく、メーリングリストのアドレスだった場合、または、そのアドレ スが別のホスト（例えば、SMTP 経由） にリルートされたときに発生します。
• ルータにより、そのアドレスがローカルのいずれかのドメインのアカウントにルートされた場 合、そのアカウントがオープンされ、その後、そのアカウントのパスワードがチェックされま す。

電子メールアドレスに対しては、上記のようにルーティングが実行されますが、そのルーティングは 結局、メーラーアプリケーションで指定されるアカウント名にも適用されます。

下は、例です。

アカウントJohn があり、そのアカウントにエイリアスとしてJohn_Smith が設定されている とします。この場合の処理は、次のようになります。
宛先がJohn_Smith のメッセージはすべて、アカウントJohn に格納されます。
ユーザーは、メーラーで「アカウント名」としてJohn またはJohn_Smith のいずれかを指定 してメッセージを送信できます。

例:

メインドメインcompany.com のアカウントJohn がセカンダリドメインclient1.com に移 動し、その名前がj.smith に変更になったします。また、管理者がルータに次のようなレコー ドを定義したとします。
<John> = j.smith@client1.com;
上のレコードにより、John@company.com 宛の電子メールはすべて、ドメイン client1.com のアカウントj.smith に格納されることになります。
上の場合、ユーザーは、以前と同じようにアカウント名としてJohn を使い、またメーラーの 「メールサーバー」の設定もcompany.com のままで、John にメッセージを送信できます。つ まり、ルータを介して、ドメインclient1.com のアカウントj.smith がサーバーによって自 動的にオープンされます。

注意:

ルータテーブルでは、メインドメインのポストマスター（Postmaster） をリダイレクトするよ うなエイリアスレコードは作成しないようにします。エイリアスを使ってポストマスターアカウント をリダイレクトし、そのエイリアスの作成元のアカウント（ポストマスターアカウント） が存在しなかったり、存在しても、そのアカウントにポストマスター権限が付与されていなかった場合、サーバー を管理する際、サーバーにアクセスできなくなります。
ポストマスター宛のメッセージを別のアカウントにリダイレクトしたい場合、ルータではなく、ポス トマスターアカウントルール を使用します。