トラブルシューティング

CommuniGate Pro では、ルーティングルールは受信メッセージだけでなく、処理対象のアドレスすべ てにも適用されます。そのため、アカウントpostmaster を別のアカウント（例えば、abc） にリ ルートし、その後、アカウントpostmaster でログインしたときには、アカウントabc が開きます。 この場合、ログイン時には、アカウントabc のパスワードを入力しなければならず、これでログイン できます。ただし、有効なアクセス権はアカウントabc に付与されているアクセス権で、したがっ て、アカウントpostmaster の作業はできません。

アカウントの名前postmaster は、アドレスにリダイレクトすることができます。この場合、アカ ウントpostmaster に従来どおりログインが可能です。postmaster をアドレスにリダイレクトす る場合、次の形式でなければなりません。

ブラウザでCommuniGate Pro に接続する際、ブラウザで指定したURL のドメイン名がチェックされま す。この名前がいずれかのセカンダリドメインの名前と同じだったときには、サーバーのWebAdmin インターフェイスではなく、そのドメインのWebAdmin インターフェイスが開きます。

サーバーのWebAdmin インターフェイスを開く場合、ブラウザのURL にメインドメインの名前を指定 します。なお、メインドメインの名前がDNS のA レコードにない場合、または、存在していても別 のサーバーを指している場合、ブラウザのURL にサーバーIP アドレスを指定します。

URL にサーバーIP アドレスを指定する場合、サーバーIP アドレスがすべて各セカンダリドメインに 割り当てられている（したがって、サーバーIP アドレスを指定できない） こともあります。こういっ たときには、CommuniGate Pro サーバーのドメインのうち、サーバーIP アドレスが割り当てられてお らず、しかも、サーバーIP アドレスが割り当てられているセカンダリドメイン以外のドメインの名前 をURL に指定します。

また、サーバーIP アドレスがすべて各セカンダリドメインに割り当てられており、かつ、CommuniGate Pro サーバーを指しているDNS ドメイン名がすべてセカンダリドメインまたはセカンダリドメインの エイリアスの場合（つまり、サーバーIP アドレスもドメイン名も使えない場合）、次のURL を使用し ます。

［Protection］ ページの［Reject all Logins from Non-Client Addresses］ オプションが有効になっており、 ［Client IP Addresses］ リスト（同じく［Protection］ ページ） にアドレスが何も登録されていない場合、 このエラーが表示されます。これは、［Reject all Logins from Non-Client Addresses］ オプションが有効 の場合、［Client IP Addresses］ リストに登録されているアドレス（IP アドレス） からの接続に限って 受け付けられ、それ以外のアドレスからユーザーがログインを試みた場合、いっさい拒否されるため です。

［Client IP Addresses］ リストにアドレスが何も登録されていないときでもログインは可能です。方法 は、CommuniGate Pro サーバーが動作しているコンピュータ上でブラウザを起動し、URL として http://127.0.0.1:8010 を指定します。これで、ローカルでログインが可能です。

［Client IP Addresses］ リストにアドレスが何も登録されておらず（または、IP アドレスを登録したも のの、そのIP アドレスからも接続できず）、また、上記のようにURL としてhttp://127.0.0.1:8010 を指定してローカルでログインすることもできなかった場合、次のようにすることでログインが可能 です。

• CommuniGate Pro サーバーを停止します。
• {base}/Settings/IPAddresses.settings ファイルを開き、［ClientOnly］ オプションの 値をYES からNO に変更します。変更後、ファイルを保存します。
• CommuniGate Pro サーバーを再起動します。

SMTP モジュールでメッセージが受信されると、Mail From コマンドに指定されているアドレス（ メッ セージの'Return-Path' アドレス） がルート処理されます。このアドレスのドメイン名がCommuniGate Pro サーバーのいずれかのドメイン名ではあるものの、アドレスのアカウント（またはオブジェクト） が、そのドメインに見つからなかったときには、ルータからエラーコードが返ります。同時に、SMTP モジュールにより、そのメッセージの受け取りが拒否されます。

上記のエラーが発生した場合、スクリプト/ アプレットを編集し、生成されたメッセージで空のReturn- Path （<>） が使われるようにするか、もしくは、既存のいずれかの電子メールアドレスが使われるよ うに定義します。スクリプト/ アプレットを編集できないときには、既存のアカウントを指すエイリ アスを作成します。

例えば、スクリプト/ アプレットでReturn-Path アドレスが のメッセージが サーバーに送信され、ドメインmydomain.com にアカウントwebform が存在しなかったときには、この エラーが発生します。この場合、アカウントpostmaster にエイリアス（webform） を作成します。これ で、メッセージの配信に失敗した場合、エラーレポートがアカウントpostmaster に送信されます。

セキュア（SSL/TLS） 接続が必要な場合、CommuniGate Pro のSMTP モジュールからリモートのメー ルホスト/ リレーに接続が実行され、セキュア接続が確立されます。このとき、ホストの証明書が取 得され、その証明書の名前がチェックされます。この名前は、メールの送信先のドメインの名前、ま たは、そのドメインのMX リレー名の名前と同じでなければなりません。そうでない場合、処理が拒 否されます。

リモートサーバーでドメインが複数ホストされており、各ドメインのIP アドレスがいずれも同じ場 合、そのリモートサーバーから送信される証明書は１ つです。これは、そのリモートサーバーではメッ セージの送信先のドメインを認識できず、したがって、どのドメインの証明書を送信すればいいか判 定できないためです。その結果、証明書がメッセージの送信先のドメインの証明書でなかった場合、 CommuniGate Pro サーバー（送り側のサーバー） で処理が拒否されることになります。

例えば、リモートサーバーmainhost.com で、mainhost.com のほか、client1.com とclient2.com の2 つの ドメインがホストされており、この3 つのドメインのMX レコードがいずれも、そのリモートサーバー の名前、IP アドレスを指しているとします。この場合、そのリモートサーバーから送られる証明書は １ つ（通常、mainhost.com の証明書） です。

ドメイン名something.com とドメイン名mail.something.com （something は任意の名前） は、全く異な ります。例えば、CommuniGate Pro サーバーのメインドメインがmycompany.dom だったとします。 この場合、WebUser インターフェイスでhttp://mail.mycompany.com:8100 と入力して mycompany.dom にアクセスしようと、ピンクのページが開き、上記のメッセージ （mail.mycompany.com domain にはアクセスできません） が表示されます。

上の理由から、mail.mycompany.com やwebmail.mycompany.com などのドメイン名を使用し たい場合、通常、mycompany.com （CommuniGate Pro のドメイン） の別名（エイリアス） を作成す るようにします。エイリアスを作成するには、ドメインmycompany.com の［Settings］ ページを開 き、［Aliases］ テーブルに移動します。このテーブルの空白のフィールドにmail.mycompany.com と入力し、［Update］ ボタンをクリックします。以上の設定で、CommuniGate Pro サーバーは、 mail.mycompany.com というドメイン名をドメインmycompany.com のエイリアスと認識するよう になります。その結果、接続要求にmail.mycompany.com というドメイン名が指定されている場 合、ドメインmycompany.com に対して接続が実行され、username@mail.mycompany.com （username はユーザー名） 宛のメッセージがドメインmycompany.com のアカウントusername に配信されます。

注意:WebAdmin インターフェイスの場合、ブラウザのURL に指定されている名前がCommuniGate Pro のドメイン名でなかったときには、その名前は自動的にメインドメインの名前と解釈されます。そ の結果、WebAdmin インターフェイス（8010） ではピンクのページは表示されず、一方、WebUser イ ンターフェイス（8100） ではピンクのページが開きます。

ユーザーがマルチホームHTTP プロキシ（AOL など大規模なISP で使用） を介してCommuniGate Pro サーバーに接続した場合、TCP 接続は、その都度、異なるIP アドレスを使って実行されます。［RequireFixed Network Address］ オプションが有効に設定されている場合（アカウントのWebUser プレファレ ンス） 、こういった環境では、ユーザーのブラウザからの接続は拒否されることがあります。そのた め、マルチホームHTTP プロキシサーバーを介して接続を行うときには、そのユーザーのアカウント の［Require Fixed Network Address］ オプションを無効にしておきます。こういったユーザーが多いと きには、デフォルトドメイン設定（ ドメインで有効） またはサーバーアカウント設定（サーバー全体 で有効） で［Require Fixed Network Address］ オプションを無効に設定します。

CommuniGate Pro サーバーが動作しているコンピュータにIP （ネットワーク） アドレスが複数割り当 てられている場合、各アドレスをCommuniGate Pro のドメインに割り当てることができます。現在、 どのIP アドレスがどのドメインに割り当てられているかは、WebAdmin インターフェイスの［Domains］ ページで確認できます。

メインドメインの場合、IP アドレスの設定（［Assigned IP Addresses］ オプション） は、デフォルトで ［All Available］ （利用できるアドレスを使用） になっています。この設定の場合、IP アドレスのうち、 セカンダリドメインに割り当てられていないIP アドレスがすべて自動的にメインドメインに割り当て られます。ここで、いずれのドメインでも、［Assigned IP Addresses］ オプションが［All Available］ に 設定されていない場合、どのドメインにもIP アドレスが割り当てられていない可能性があります（利 用可能なアドレスは全部、メインドメインで使用されます）。

上のような状態で、ユーザーがPOP クライアントまたはIMAP クライアントでアカウント名だけを指 定して（ ドメイン名なし） サーバーに接続しようとしたとき、または、その接続がセキュア（SSL/ TLS） 接続だったときには、ユーザーの接続先のローカルIP アドレスが取り出され、そのアドレスに 対応するドメイン（そのアドレスが割り当てられているドメイン） が検索されます。ここで、どのド メインにもローカルIP アドレスが割り当てられていなかったときには、上記の"unassigned local network address （未割り当てのローカルネットワークアドレス） " エラーが表示されます。

このエラーが表示された場合、WebAdmin インターフェイスで［Settings］ セクションの［General］ ペー ジを開き、サーバーのローカルIP アドレスをチェックします。［Refresh］ ボタンをクリックすると、 ローカルIP アドレスがすべて表示されます。アドレスのうち、未割り当てのアドレスは赤で示されま すので、必要に応じてアドレスを割り当てます。

ほとんどのLDAP クライアント（Microsoft Outlook/Outlook Express を含む） ではディレクトリサブツ リーに関する設定が可能で、この機能により検索処理を実行できます。Outlook Express の場合、この 設定は、［Directory Account Properties］ パネル（ ［Advanced］ タブ） にあります。この設定はサーチ ベースとも呼ばれており、ユーザーのドメインのDN （識別名） を指定します（デフォルトでは、こ のDN はcn=domainname です）。

Microsoft Outlook/Outlook Express では、この設定フィールドを空白にしておくと値として自動的に文 字列c=country_code が使われ、その結果、検索処理は失敗します（ただし、ディレクトリにサブ ツリーc=country_code があれば検索は成功します）。

Microsoft Outlook/Outlook でもディレクトリ全体の検索は可能で、この検索処理を行いたい場合、サー チベース設定フィールドに文字列top を指定します。

この問題は、サーバーマシンまたはクライアントマシンのタイムゾーンの設定が正しくないと発生し ます。サーバーマシンのタイムゾーンの設定は、WebAdmin インターフェイスの［Settings］ セクショ ンの［General］ ページを開くとチェックできます。ページに［Server Time］ フィールドがありますの で、このフィールドの日付と時刻が正しいかどうかを確認します。また、タイムゾーンの設定が正し いかどうかもチェックします。この場合、-0800 はGMT より8 時間遅いこと、+0800 はGMT より8 時間早いことを示します。

タイムゾーンの値が間違っている場合、OS の設定を修正した後、再度、［General］ ページを開いてタ イムゾーンの値を確認します。

WebAdmin インターフェイスの場合、ブラウザのURL に指定されたドメイン名には自動的に文字列 LoginPage@ が追加され、そのアドレスが電子メールアドレスとしてルートされます。このルート処 理に失敗したときには、WebAdmin インターフェイスはメインドメイン（サーバーWebAdmin インター フェイス） に戻ります。同時に、失敗レコードが出力されます。例えば、次のようになります。

CommuniGate Pro サーバーに送られるメールの送信元のサーバーのIP アドレスをRBL を使ってチェッ クしている場合、SMTP モジュールによって、そのサーバーのIP アドレス（例えば、aa.bb.cc.dd） が dd.cc.bb.aa. rbl-server-nameという形式のドメイン名（ rbl-server-nameは、RBL サーバー名） に自動的 に変換されます。その後、DNS システムを使って、その名前のリゾルブが実行されます。ここで、そ のサーバーが既知の不正サーバーではなく、また、そのアドレスがRBL データベースにもなく、さら に、そのドメイン名がDNS システムにも存在しなかった場合、DNR モジュールにより、上記のログ レコード（ ログレベルはProblem） が生成されます。

RBL サーバーを使用する場合、DNR モジュールのログレベルを［Major & Failures］ に設定すると、こ のログレコードは出力されなくなります。

DNR （ ドメイン名リゾルバ） ソケットです。このソケットのポート番号はOS によって選択され、 CommuniGate Pro サーバーを再起動するとポート番号が変わります。このソケットを使って、要求 （UDP パケット） がDNS サーバーに送信され、また、DNS サーバーからの応答が受信されます。

CommuniGate Pro サーバー以外のアプリケーション（サーバー、ブラウザなど） でも、このタイプ （UDP） のソケットを使ってドメイン名がリゾルブされます。ただし、通常、ソケットはオープン後、 すぐに閉じます。そのため、netstat 出力では分かりません。一方、CommuniGate Pro の場合、起動時 にUDP ソケットがオープンされ、そのソケットを使ってDNR 要求がすべて継続して処理されます。 このUDP ソケットは、CommuniGate Pro サーバーのシャットダウンと同時に閉じます。