test

Sun Java System Messaging Server 6 2005Q4 管理ガイド

第 22 章 MTA のトラブルシューティング

この章では、MTA (Message Transfer Agent) のトラブルシューティングのための一般的なツール、方法、手順について説明します。この章には、次の節があります。

監視手順に関連する項目は、第 23 章「Messaging Server を監視する」で参照できます。

注 –

この章を読む前に、このマニュアルの第 5 章から第 10 章と、『 Sun Java System Messaging Server Administration Reference』の MTA 設定およびコマンド行ユーティリティーに関する章をもう一度確認してください。

トラブルシューティングの概要

MTA トラブルシューティングの最初の段階の 1 つは、診断を始める場所を決めることです。該当する問題によって、ログファイルにあるエラーメッセージを検索することもできます。また、標準 MTA プロセスのすべてをチェックしたり、MTA 設定を見直したり、個々のチャネルを起動して停止することもできます。どの方法を使用する場合も、MTA のトラブルシューティングを行う際は次の点を考慮してください。

この章の以下の節で、これらの問題に対する処置を説明しています。

MTA のトラブルシューティングの標準的な手順

この節では、MTA のトラブルシューティングの標準的な手順の概要を説明します。問題が発生してもエラーメッセージが生成されない場合、エラーメッセージに十分な診断情報がない場合、あるいは MTA の全般的な状況のチェック、テスト、および標準的な保守を行う場合は、以下の手順に従ってください。

MTA 設定をチェックする

imsimta test -rewrite ユーティリティーを使って、アドレス設定をテストしてください。このユーティリティーを使うと、実際にメッセージを送信することなく、MTA のアドレス書き換えとチャネルマッピングをテストすることができます。詳細は、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の第 2 章「Message Transfer Agent Command-line Utilities」の MTA コマンド行ユーティリティーの章を参照してください。

通常このユーティリティーは、メッセージをキューに入れるチャネルとともに、適用されるアドレス書き換えを表示します。ただし、このユーティリティーは、MTA 設定の構文エラーが発生すると、エラーメッセージを発行します。出力が希望するものでない場合は、設定を修正することもできます。

メッセージキューディレクトリをチェックする

MTA メッセージキューディレクトリ (通常、msg_svr_base/data/queue/) にメッセージがあるかどうかをチェックします。希望するメッセージファイルが MTA メッセージキューディレクトリにあるかどうかをチェックするには、imsimta qm のようなコマンド行ユーティリティーを使用します。imsimta qm の詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「imsimta qm」の MTA コマンド行ユーティリティーの章と 「imsimta qm counters」を参照してください。

imsimta test -rewrite の出力が正しいようであれば、メッセージが実際に MTA メッセージキューサブディレクトリに置かれているかどうかをチェックします。これを行うには、メッセージのログを有効にします (MTA ログの詳細については、「MTA メッセージおよび接続のログの管理」を参照)。次に、ディレクトリ / msg_svr_base/log/ にある mail.log_current ファイルを調べます。特定のメッセージをそのメッセージ ID で追跡して、メッセージが MTA メッセージキューサブルーチンに置かれていることを確認できます。メッセージが見つからない場合は、ファイルのディスク容量やディレクトリアクセス権に関する問題がある可能性があります。

危険なファイルの所有権をチェックする

Messaging Server をインストールしたときに、メールサーバーのユーザーアカウント (デフォルトでは nobody) を選択したはずです。次に示すディレクトリ、サブディレクトリ、およびファイルは、このアカウントが所有している必要があります。


/msg_svr_base/data/queue/
/msg_svr_base/log
/tmp

以下の UNIX システムのコマンド例にあるようなコマンドを使用して、これらのディレクトリの保護と所有権をチェックできます。


ls -l -p -d /opt/SUNWmsgsr/data/queue
drwx------ 6 inetuser bin 512 Feb 7 09:32 /opt/SUNWmsgsr/data/queue

ls -l -p -d /opt/SUNWmsgsr/log/imta
drwx------ 2 inetuser bin 1536 Mar 10 09:00 /opt/SUNWmsgsr/log/imta

ls -l -p -d /opt/SUNWmsgsr/imta/tmp
drwx------ 2 inetuser bin 512 Feb 7 10:00 /opt/SUNWmsgsr/imta/tmp

次の UNIX システムのコマンド例のようなコマンドを使用して、/msg_svr_base/data/queue にあるファイルが MTA アカウントによって所有されていることをチェックします。

ls -l -p -R /opt/SUNWmsgsr/data/queue

ジョブコントローラとディスパッチャーが実行中であることをチェックする

MTA ジョブコントローラは、大半の送信 (マスター) チャネルジョブなどの、MTA が処理するジョブの実行を行います。

MTA チャネルの中には、MTA のマルチスレッド SMTP チャネルのように、着信メッセージを処理する常駐サーバープロセスを含むものもあります。このようなサーバーは、チャネルのスレーブ (着信) 方向を扱います。MTA ディスパッチャーは、そのような MTA サーバーの作成を行います。ディスパッチャーの設定オプションは、サーバーの可用性、作成されたサーバーの数、各サーバーが処理できる接続の数を制御します。

ジョブコントローラとディスパッチャーがあるかどうかをチェックし、MTA サーバーと処理するジョブが実行中かどうかを確認するには、imsimta process コマンドを使用します。このコマンドは、アイドル状態では job_controller および dispatcher プロセスになります。次に例を示します。


# imsimta process
USER      PID S VSZ    RSS   STIME    TIME     COMMAND
inetuser 9567 S 18416 9368  02:00:02  0:00  /opt/SUNWmsgsr/lib/tcp_smtp_server
inetuser 6573 S 18112 5720  Jul_13    0:00  /opt/SUNWmsgsr/lib/job_controller
inetuser 9568 S 18416 9432  02:00:02  0:00  /opt/SUNWmsgsr/lib/tcp_smtp_server
inetuser 6574 S 17848 5328  Jul_13    0:00  /opt/SUNWmsgsr/lib/dispatcher

ジョブコントローラがない場合、/msg_svr_base/data/queue ディレクトリにあるファイルはバックアップされ、メッセージは配信されません。ディスパッチャーがなければ、SMTP 接続を受信することはできません。

imsimta process の詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「imsimta process」を参照してください。

ジョブコントローラもディスパッチャーもない場合は、/msg_svr_base/data/log にある dispatcher.log-* または job_controller.log-* ファイルを確認します。

ログファイルが存在しないか、エラーが示されていない場合は、start-msg コマンドを使ってプロセスを開始してください。詳細は、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「start-msg」の MTA コマンド行ユーティリティーの章を参照してください。

注 –

実行が必要なプログラムを実行する (exec()) 前に子プロセスをフォークしている (fork()) 場合を除き、imsimta process を実行するときは、ディスパッチャーまたはジョブコントローラの複数のインスタンスを表示しないようにしてください。ただし、このような重複が発生しているのは非常に短い期間です。

ログファイルをチェックする

MTA が処理するジョブが正常に実行されていても、メッセージがメッセージキューディレクトリに残っている場合は、ログファイルを調べて何が起きているかを見ることができます。すべての MTA ログファイルは、ディレクトリ /msg_svr_base/log に作成されます。表 22–1 に、MTA が処理するさまざまなジョブのログファイル名の形式を示します。

表 22–1 MTA ログファイル

ファイル名 

ログファイルの内容 

channel_master.log-uniqueid

channel のマスタープログラム (通常はクライアント) の出力。

channel_slave.log- uniqueid

channel のスレーブプログラム (通常はサーバー) の出力。

dispatcher.log-uniqueid

ディスパッチャーのデバッグ。このログは、ディスパッチャーの DEBUG オプションが設定されているかどうかにかかわらず作成されます。ただし、デバッグの詳細情報を入手するには、DEBUG オプションをゼロ以外の値に設定する必要があります。

imta

配信に関する問題が発生した場合の ims-ms チャネルのエラーメッセージ。

job_controller.log-uniqueid

ジョブコントローラのログ。このログは、ジョブコントローラの DEBUG オプションが設定されているかどうかにかかわらず作成されます。ただし、デバッグの詳細情報を入手するには、DEBUG オプションをゼロ以外の値に設定する必要があります。

tcp_smtp_server.log-uniqueid

tcp_smtp_server のデバッグ。このログ内の情報はサーバー固有の情報であり、メッセージに対するものではありません。

return.log-uniqueid

定期的な MTA メッセージバウンサジョブのデバッグ出力。option.dat 内で return_debug オプションを使用している場合は、このログファイルが作成されます

注 –

各ログファイルの作成時には、同一のチャネルが作成した過去のログが上書きされないよう、ファイル名に固有の ID (uniqueid) が付加されています。特定のログファイルを見つける際は、imsimta view ユーティリティーを使用できます。imsimta purge コマンドを使用して、古いログファイルを消去することもできます。詳細は、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「imsimta purge」の MTA コマンド行ユーティリティーの章を参照してください。

channel_master.log-uniqueid および channel_slave.log-uniqueid のログファイルは、次のような状況で作成されます。

チャネルのマスターおよびスレーブプログラムのデバッグについては、『 Sun Java System Messaging Server Administration Reference』を参照してください。

チャネルプログラムを手動で実行する

MTA の配信問題を診断するときは、特に、1 つ以上のチャネルに対するデバッグを有効にしたあとで、MTA 配信ジョブを手動で実行することをお勧めします。

imsimta submit コマンドは、MTA ジョブコントローラにチャネルの実行を通知します。問題のチャネルに対してデバッグが有効になっている場合は、表 22–1 で示すように、imsimta submit でディレクトリ /msg_svr_base/log 内にログファイルが作成されます。

imsimta run コマンドは、現在アクティブなプロセスのもとでチャネルに対する送信を実行し、また、端末に出力を送信します。ジョブの送信自体に問題があると思われる場合は特に、ジョブを送信するよりもこの方法をお勧めします。

注 –

チャネルを手動で実行するには、ジョブコントローラが実行されている必要があります。

imsimta submit コマンドと imsimta run コマンドの構文、オプション、パラメータ、例の詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「Command Descriptions」を参照してください。

個々のチャネルを起動および停止する

場合によっては、個々のチャネルを停止して再起動することで、メッセージキューの問題の診断とデバッグが行いやすくなることもあります。メッセージキューを停止して、キューに入れられたメッセージを検査し、ループまたはスパム攻撃があるかどうかを確認することができます。

Procedure特定のチャネルへの送信処理 (キューからの取り出し) を停止するには

手順

  1. imsimta qm stop コマンドを使用して、特定のチャネルを停止します。これにより、ジョブコントローラを停止する必要がなくなり、設定を再コンパイルしなくてすみます。次の例では、conversion チャネルを停止しています。

    imsimta qm stop conversion

  2. 処理を再開するには、imsimta qm start コマンドを使用してチャネルを再起動します。次の例では、conversion チャネルを起動しています。

    imsimta qm start conversion

    imsimta qm start コマンドと imsimta qm stop コマンドの詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「imsimta qm」を参照してください。

特定のドメインまたは IP アドレスからの受信処理 (チャネルのキューに入れる) を停止するには

クライアントホストに一時的なSMTP エラーを返している間に、特定のドメインまたはIP アドレスからの受信メッセージ処理を停止したい場合は、次の操作のいずれかを実行することができます。これを実行すると、メッセージはシステム上に保持されることはありません。詳細については、「第 1 部 マッピングテーブル」を参照してください。

ORIG_SEND_ACCESS 

  *|*@sesta.com|*|*        $X4.2.1|$NHost$ blocked

このようにすると、差出人のリモート MTA はメッセージをシステム上に保持し、受信処理を再開するまで定期的にそのメッセージを再送信し続けるようになります。

PORT_ACCESS

    TCP|*|25|IP_address_to_block|*    $N500$ can't$ connect$ now

ドメインまたは IP アドレスからの受信処理を再開するときは、必ず上記のルールをマッピングテーブルから削除し、設定を再コンパイルしてください。さらに、各マッピングテーブルごとに固有のエラーメッセージを作成することもできます。これを行うことで、使用中のマッピングテーブルを確認することができます。

MTA のトラブルシューティングの例

この節では、特定の MTA の問題のトラブルシューティング方法をステップバイステップで説明します。この例では、メールの受取人は電子メールメッセージの添付ファイルを受信しませんでした。注: MIME プロトコルの用語に沿って、この節では「添付ファイル」のことを「メッセージ部分」と呼びます。前述のトラブルシューティング方法を使用して、メッセージ部分が見えなくなった場所と原因を確認します (「MTA のトラブルシューティングの標準的な手順」を参照)。次の手順で、メッセージが MTA を通じてとるパスを確認することができます。さらに、メッセージ部分が見えなくなったのがキューに入れられる前後かどうかを確認することができます。これを行うには、関連ファイルを取り込みながら、チャネルを手動で停止してから起動する必要があります。

注 –

メッセージをチャネルを通じて手動で起動するときは、ジョブコントローラが実行されている必要があります。

メッセージパスにあるチャネルを識別する

メッセージパスにあるチャネルを識別することによって、該当するチャネルに master_debug および slave_debug キーワードを適用することができます。これらのキーワードはチャネルのマスターおよびスレーブログファイルにデバッグ出力を生成します。そのマスターおよびスレーブデバッグ情報により、メッセージ部分が見えなくなった場所が識別しやすくなります。

  1. ディレクトリ /msg_svr_base/config にある option.dat ファイルに log_message_id=1 を追加します。このパラメータにより、メッセージ ID: ヘッダー行が mail.log_current ファイルに表示されます。

  2. imsimta cnbuild を実行して設定を再コンパイルします。

  3. imsimta restart dispatcher を実行して、SMTP サーバーを再起動します。

  4. エンドユーザーにメッセージ部分を含むメッセージを再送信してもらいます。

  5. メッセージが通過するチャネルを確認します。

    チャネルを識別する方法にはいろいろありますが、次の方法をお勧めします。

    1. UNIX プラットフォームの場合は、grep コマンドを使用して、メッセージ ID: ヘッダー行を /msg_svr_base/log ディレクトリにある mail.log_current ファイルで検索します。

    2. メッセージ ID: ヘッダー行が見つかったら、E (キューに入れる) および D (キューから取り出す) レコードを検索して、メッセージのパスを確認します。ログエントリコードの詳細については、「MTA ログエントリの形式について」を参照してください。この例の場合は、次の E および D レコードを見てください。


      29-Aug-2001 10:39:46.44  tcp_local conversion        E 2 ... 
29-Aug-2001 10:39:46.44  conversion tcp_intranet     E 2 ... 
29-Aug-2001 10:39:46.44  tcp_intranet                  D 2 ...

左側のチャネルはソースチャネルで、右側のチャネルは宛先チャネルです。この例では、E レコードと D レコードは、メッセージのパスが tcp_local チャネルから conversion チャネルに移り、最後に tcp_intranet チャネルに移っていることを示しています。

データを収集するためにチャネルを手動で起動および停止する

この節では、チャネルを手動で起動したり停止したりする方法を説明します。詳細については、「個々のチャネルを起動および停止する」を参照してください。メッセージのパスにあるチャネルを手動で起動したり停止することによって、メッセージとログファイルを MTA プロセスのさまざまな段階で保存することができます。これらのファイルは、後述の 「メッセージに問題が発生した場所を確認するには」で使用されます。

Procedureチャネルを手動で起動および停止するには

手順

  1. 十分なデバッグ情報を提供するためには、ディレクトリ /msg_svr_base/config にある option.dat ファイルに mm_debug=5 を設定します。

  2. ディレクトリ /msg_svr_base/config 内の imta.cnf ファイルにある該当するチャネルに、slave_debug キーワードと master_debug キーワードを追加します。

    1. リモートシステムから送信されるメッセージ部分を含むメッセージの受信チャネル (または最初のダイアログの間にメッセージが切り替えられるチャネル) で、slave_debug キーワードを使用します。この例では、slave_debug キーワードが tcp_local チャネルに追加されています。

    2. メッセージが通過し、「メッセージパスにあるチャネルを識別する」で識別されたほかのチャネルに、master_debug キーワードを追加します。この例では、master_debug キーワードは conversion チャネルと tcp_intranet チャネルに追加されます。

    3. imsimta restart dispatcher コマンドを実行して SMTP サーバーを再起動します。

  3. imsimta qm stop コマンドと imsimta qm start コマンドを使用して、特定のチャネルを起動および停止します。これらのキーワードの使用の詳細については、「個々のチャネルを起動および停止する」を参照してください。

  4. メッセージファイルの取り込み処理を開始するために、エンドユーザーにメッセージ部分を含むメッセージを再送信してもらいます。

  5. メッセージがチャネルに入るときに、メッセージが imsimta qm stop コマンドによって停止されていると、メッセージはチャネル内で停止します。詳細については、手順 3 を参照してください。

    1. メッセージのパスにある次のチャネルを手動で起動する前に、メッセージファイルをコピーして名前を変更します。次の UNIX プラットフォームの例を見てください。

      # cp ZZ01K7LXW76T7O9TD0TB.00 ZZ01K7LXW76T7O9TD0TB.KEEP1

      通常、メッセージファイルは、/msg_svr_base/data/queue/destination_channel/001 のようなディレクトリにあります。destination_channel は、メッセージが通過する次のチャネル (tcp_intranet など) です。destination_channel ディレクトリにサブディレクトリ (001、002 など) を作成する場合は、チャネルにsubdirs キーワードを追加します。

    2. メッセージが処理される順番を識別するために、メッセージをトラップしてコピーするたびに、メッセージの拡張子に番号を付けることをお勧めします。

  6. チャネルでメッセージの処理を再開し、メッセージのパスにある次の宛先チャネルのキューに入れます。これを行うには、imsimta qm start コマンドを使用します。

  7. Copy and save the corresponding channel log file (for example: /msg_svr_base/log. ディレクトリにある対応するチャネルログファイル (たとえば、 tcp_intranet_master.log-*) をコピーして、保存します。追跡しているメッセージのデータを含む該当するログファイルを選択します。必ず、コピーするファイルが、チャネルで受信するメッセージのタイムスタンプおよび Subject ヘッダーと一致するようにします。tcp_intranet_master.log-* の例では、ファイルが削除されないように、ファイルを tcp_intranet_master.keep という名前で保存しています。

  8. 最終的な宛先に達するまで、手順 5 〜 7 を繰り返します。

    手順 7 でコピーしたログファイルは、手順 5 でコピーしたメッセージファイルと相互に関連させる必要があります。たとえば、メッセージ部分がないためにすべてのチャネルを停止した場合は、conversion_master.log-* ファイルと tcp_intranet_master.log-* ファイルを保存します。ソースチャネルのログファイル tcp_local_slave.log-* も保存します。さらに、それぞれの宛先チャネルの対応するメッセージファイルのコピーを保存します。つまり、conversion チャネルの ZZ01K7LXW76T7O9TD0TB.KEEP1、tcp_intranet チャネルの ZZ01K7LXW76T7O9TD0TB.KEEP2 を保存します。

  9. メッセージとログファイルがコピーされたら、デバッグオプションを削除します。

    1. ディレクトリ / msg_svr_base/config 内の imta.cnf ファイルにある該当するチャネルから、slave_debug キーワードと master_debug キーワードを削除します。

    2. mm_debug=0 をリセットし、ディレクトリ / msg_svr_base/config の option.dat ファイルにある log_message_id=1 を削除します。

    3. imsimta cnbuild を使用して設定を再コンパイルします。

    4. imsimta restart dispatcher コマンドを実行して SMTP サーバーを再起動します。

Procedureメッセージに問題が発生した場所を確認するには

手順

  1. チャネルプログラムの起動と停止が終わるまでには、トラブルシューティングのために使用できる次のファイルがあるはずです。

    1. 各チャネルプログラムのメッセージファイルのすべてのコピー (たとえば、ZZ01K7LXW76T7O9TD0TB.KEEP1)

    2. tcp_local_slave.log-* ファイル

    3. 各宛先チャネルの channel_master.log-* ファイルのセット

    4. メッセージのパスを示す mail.log_current レコードのセット

      すべてのファイルには、mail.log_current レコードにあるメッセージ ID: ヘッダー行に一致するタイムスタンプ値とメッセージ ID 値がある必要があります。メッセージが受取人にバウンスされた場合は例外です。バウンスされたメッセージには元のメッセージとは異なるメッセージ ID 値が付いています。

  2. tcp_local_slave.log-* ファイルを調べて、メッセージがキューに入れられたときにメッセージにメッセージ部分があったかどうかを確認します。

    SMTP ダイアログとデータを見て、クライアントマシンから何が送信されたかを確認します。

    メッセージ部分が tcp_local_slave.log-* ファイルになかった場合、問題が発生したのはメッセージが MTA に入る前です。結果として、メッセージはメッセージ部分なしでキューに入れられています。このような場合、問題は、差出人のリモート SMTP サーバーまたは差出人のクライアントマシンで発生した可能性があります。

  3. メッセージファイルを詳しく調べて、メッセージ部分が変更されたり欠落したりした場所を確認します。

    メッセージファイルにメッセージ部分が変更されたり欠落したりしたことが示されていた場合は、前のチャネルのログファイルを調べます。たとえば、tcp_intranet チャネルに入っているメッセージのメッセージ部分が変更されたり欠落したりした場合は、conversion_master.log-* ファイルを確認する必要があります。

  4. メッセージの最終的な宛先を確認します。

    tcp_local_slave.log、メッセージファイル (例: ZZ01K7LXW76T7O9TD0TB.KEEP1)、および channel_master.log-* ファイルでメッセージ部分が変更されていないようであれば、MTA がメッセージを変更したのではなく、メッセージ部分は最終的な宛先へのパスの次のステップで消えています。

    最終的な宛先が ims-ms チャネル (メッセージストア) である場合は、メッセージ部分がこの転送の間または転送のあとに欠落したかどうかを確認するために、メッセージをサーバーからクライアントマシンにダウンロードすることもできます。宛先チャネルが tcp_* チャネルの場合は、メッセージのパスにある MTA に移動する必要があります。Messaging Server の MTA の場合は、トラブルシューティング処理すべてを繰り返す必要があります (「メッセージパスにあるチャネルを識別する」、「データを収集するためにチャネルを手動で起動および停止する」、およびこの節を参照)。その他の MTA が自分の管理下にない場合は、問題を報告したユーザーが特定のサイトに問い合わせる必要があります。

一般的な MTA の問題と解決策

この節では、MTA の設定と操作で一般的に起こりやすい問題と解決策を示します。

TLS の問題

SMTP ダイアログの間に、STARTTLS コマンドが次のエラーを返した場合で、

454 4.7.1 TLS library initialization failure

かつ証明書をインストール済みで pop/imap アクセスを試みている場合は、次のことを確認します。

保護を変更し、証明書をインストールしたら、次のコマンドを実行します。


stop-msg dispatcher 
start-msg dispatcher

再起動でも問題は解決するはずですが、完全にシャットダウンして証明書をインストールしてから操作をやり直すことをお勧めします。

設定ファイルまたは MTA データベースに対する変更が有効にならない

設定、マッピング、変換、セキュリティー、オプション、またはエイリアスファイルに対する変更が有効になっていない場合は、次の手順を実行したかどうかをチェックします。

  1. 設定の再コンパイル (imsimta cnbuild を実行)。

  2. 該当するプロセス (imsimta restart dispatcher など) の再起動。

  3. クライアント接続の再確立。

MTA が、メールを送信するが受信しない

ほとんどの MTA チャネルは、スレーブまたはチャネルプログラムに依存して、着信メッセージを受信します。MTA がサポートしているいくつかの転送プロトコル (TCP/IP や UUCP など) の場合、転送プロトコルが標準サーバーではなく MTA スレーブプログラムをアクティブにしていることを確認する必要があります。ネイティブの sendmail SMTP サーバーから MTA の SMTP サーバーへの置換は、Messaging Server のインストールの際に実行されます。詳細は、『Sun Java Enterprise System 2005Q4 インストールガイド』を参照してください。

マルチスレッド SMTP サーバーの場合、SMTP サーバーの起動はディスパッチャーによって制御されます。ディスパッチャーが SMTP サービスより大きいか等しい MIN_PROCS 値を使用するように構成されている場合は、少なくとも 1 つの SMTP サーバープロセスが常に実行されている必要があります (SMTP サービスの MAX_PROCS 値によっては複数の場合もある)。imsimta process コマンドを使用して、SMTP サーバープロセスがあるかどうかをチェックすることもできます。詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「imsimta process」を参照してください。

ディスパッチャー (SMTP サーバー) が起動しない

ディスパッチャーが起動しない場合は、まず dispatcher.log-* に関連するエラーメッセージがあるかどうか確認します。/tmp/.SUNWmsgsr.dispatcher.socket ファイルの作成やアクセスに関する問題がログで示されている場合は、/tmp 保護が 1777 に設定されていることを確認します。これは、権限で次のように表示されます。


drwxrwxrwt 8 root sys 734 Sep 17 12:14 tmp/
.

また、.SUNWmsgsr.dispatcher.socket ファイルの ls -l を実行して、適切な所有権を確認します。たとえば、このファイルが root によって作成された場合は、inetmail でアクセスすることはできません。

Do not remove the ..SUNWmsgsr.dispatcher.file を削除しないでください。また、存在しない場合は作成しないでください。このファイルはディスパッチャーによって作成されます。保護が 1777 に設定されていないと、ディスパッチャーはソケットファイルを作成およびアクセスできないため、起動または再起動しません。また、Messaging Server とは関連のないほかの問題が発生している可能性もあります。

着信 SMTP 接続時のタイムアウト

着信 SMTP 接続時のタイムアウトは、システムリソースやその割り当てに関連していることがよくあります。次の方法を使用して、着信 SMTP 接続時のタイムアウトの原因を識別することができます。

Procedure着信 SMTP 接続時のタイムアウトの原因を識別するには

手順

  1. 同時に許可する着信 SMTP 接続の数をチェックします。これは SMTP サービスのディスパッチャー設定である MAX_PROCS および MAX_CONNS によって制御され、許可できる同時接続数は MAX_PROCS*MAX_CONNS です。接続数が少なすぎる場合、システムリソースに余裕があれば、この数を増やすことを考慮してください。

  2. 使用できるもう 1 つの方法は、TELNET セッションを開くことです。

    次の例では、ユーザーは 127.0.0.1 ポート 25 に接続しています。接続すると、220 バナーが返されます。次に例を示します。


    telnet 127.0.0.1 25
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is ’^]’.
220 budgie.sesta.com --Server ESMTP (Sun Java System Messaging Server 6.1 
(built May  7 2001))

    接続して 220 バナーを受信しても、その他のコマンド (ehlo や mail from など) が応答を不正としない場合は、imsimta test -rewrite を実行して設定が正しいことを確認する必要があります。

  3. 220 バナーの応答が遅い場合や、SMTP サーバーで pstack コマンドを実行すると次の iii_res* 関数 (名前解決検索が実行されていることを示す) が表示される場合があります。


    febe2c04 iii_res_send (fb7f4564, 28, fb7f4de0, 400, fb7f458c, fb7f4564) + 
42c febdfdcc iii_res_query (0, fb7f4564, c, fb7f4de0, 400, 7f) + 254

    このような場合は、localhost/127.0.0.1 のような一般的なペアでも、ホストが名前解決のリバース検索を行う必要があることも考えられます。このようなパフォーマンスの低下を回避するには、/etc/nsswitch.conf ファイルでのホストの検索順を並べ替えてください。このためには、/etc/nsswitch.conf ファイルの次の行を変更します。


    hosts: dns nis [NOTFOUND=return] files

    変更後は次のようになります。


    hosts: files dns nis [NOTFOUND=return]

    /etc/nsswitch.conf ファイルでこのような変更を行うと、複数の SMTP サーバーで不要な検索を実行する必要がなく、少数の SMTP サーバーでメッセージを処理するため、パフォーマンスを向上させることができます。

  4. 着信 SMTP over TCP/IP メールを処理しているチャネル (通常は、tcp_local と tcp_intranet) 上に slave_debug キーワードを設定することもできます。これを実行したあと、最新の tcp_local_slave.log-uniqueid ファイルを見直して、タイムアウトになったメッセージの特性を識別します。たとえば、受取人の数が多すぎる着信メッセージがタイムアウトになった場合は、チャネル上で expandlimit キーワードを使用することを考慮してください。

    システムが過負荷になっていて拡張されすぎている場合は、タイムアウトを完全に回避するのは難しくなります。

メッセージがキューから取り出されない

TCP/IP 配信中に発生したエラーは、一時的なことがよくあります。通常、MTA は、問題が発生したときにメッセージを残し、それを定期的に再試行します。大規模なネットワークでは通常、あるホスト上で定期的な機能停止が起こっても、ほかのホスト接続は適切に作動しています。問題を検証するには、配信試行に関連するエラーのログファイルを調べます。「smtp_open の致命的なエラー」のようなエラーメッセージが記述されていることもあります。このようなエラーは特別なものではなく、通常はネットワークに関する一時的な問題と関連しています。TCP/IP ネットワークに関する問題をデバッグするには、PING、TRACEROUTE、NSLOOKUP のようなユーティリティーを使用します。

次の例は、メッセージが xtel.co.uk への配信待ちでキューに入ったままになっている理由を確認するためのステップを示しています。メッセージがキューから取り出されない理由を確認するには、MTA が TCP/IP 上で SMTP メールを配信するために使用するステップを再作成することができます。


% nslookup -query=mx xtel.co.uk (手順 1)
            
Server: LOCALHOST
Address: 127.0.0.1

Non-authoritative answer:
XTEL.CO.UK  preference = 10, mail exchanger = nsfnet-relay.ac.uk (手順 2)

% telnet nsfnet-relay.ac.uk 25 (手順 3)
Trying... [128.86.8.6]
telnet: Unable to connect to remote host: Connection refused

  1. NSLOOKUP ユーティリティーを使用して、MX レコードが存在する場合、どの MX レコードがこのホストに存在しているかを確認します。MX レコードが存在していない場合、直接ホストへの接続を試みる必要があります。MX レコードが存在している場合、指定された MX リレーに接続する必要があります。MTA は MX 情報を優先して処理します (優先して処理しないように設定されている場合は除く)。「TCP/IP MX レコードのサポート」も参照してください。

  2. この例では、DNS (ドメインネームサービス) は xtel.co.uk の指定された MX リレーの名前を返しています。これは MTA の実際の接続先になるホストです。複数の MX リレーがリストにある場合、MTA は各 MX レコードを、優先度がもっとも低いものから順に、連続して試行します。

  3. リモートホストへの接続がある場合は、SMTP サーバーのポート 25 への TELNET を使用して、受信 SMTP 接続を受け入れているかどうかチェックする必要があります。

    注 –

    ポートを指定しないで TELNET を使用すると、リモートホストが通常の TELNET 接続を受け入れることがわかります。これは、SMTP 接続を受け入れることを示すわけではありません。多くのシステムは、正規の TELNET 接続は受け入れても SMTP 接続は拒否します。または、その逆になります。そのため、常に SMTP ポートのテストを行う必要があります。

    前述の例では、リモートホストは SMTP ポートへの接続を拒否しています。これが、MTA がメッセージの配信に失敗した理由です。この接続は、リモートホストの設定ミスやリモートホスト上での何らかのリソース不足のために拒否されることがあります。このような場合は、ローカルで問題解決を行うことはできません。通常は、MTA にメッセージの再試行を続けさせることになります。

DNS を使用しない TCP/IP ネットワーク上で Messaging Server が稼動している場合は、最初の 2 つの手順を省略することができます。代わりに、TELNET を使用して、問題となっているホストに直接アクセスすることができます。MTA が使用するホスト名と同じホスト名を使用する際は、注意してください。ホスト名を確認するには、MTA の最後の試行に関連するログファイルを確認します。ホストファイルを使用している場合は、ホスト名情報が正しいことを確認する必要があります。ホスト名ではなく DNS を使用することを、強くお勧めします。

TCP/IP ホストへの接続をテストする場合、インタラクティブテストを使用して問題が発生しないのであれば、ほぼ確実に、問題は MTA が最後にメッセージを配信しようとしたあとに解決されています。該当するチャネルで imsimta submit tcp_channel を再度実行して、メッセージがキューから取り出されているかどうかを確認することができます。

新しいチャネルを作成するには

状況によっては、リモートドメインに問題が発生し、このサーバー宛のメールが大量にあると、配信できないメッセージで送信チャネルキューがいっぱいになることがあります。MTA はこれらのメッセージの再配信を定期的に試行するので (再試行の頻度と回数は backoff キーワードで設定可能)、通常の状況では操作は必要ありません。ただし、多くのメッセージがキューに溜まると、配信できないメッセージのバックログを処理するためにすべてのチャネルジョブが使用され、ほかのメッセージが適時に配信されなくなることがあります。

このような場合は、独自のジョブコントローラプールで実行されている新しいチャネルにこれらのメッセージを再ルーティングすることもできます。これによって処理の競合が回避され、ほかのチャネルはそれぞれのメッセージを配信できるようになります。次に、この手順を説明します。ここでは siroe.com というドメインを仮定しています。

Procedure新しいチャネルを作成するには

手順

  1. tcp_siroe-daemon という新しいチャネルを作成し、pool キーワードの新しい値を追加します。

    チャネルは /msg_svr_base/config/imta.cnf のチャネルブロックセクションに作成されます。このチャネルには、通常の送信 tcp_* チャネルと同じチャネルキーワードを設定します。通常、これはすべての送信 (インターネット) トラフィックを処理する tcp_local チャネルです。siroe.com は外部のインターネット上にあるので、これがエミュレートするチャネルになります。新しいチャネルは次のようになります。

    tcp_siroe smtp nomx single_sys remotehost inner allowswitchchannel     \
dentnonenumeric subdirs 20 maxjobs 7 pool SMTP_SIROE maytlsserver      \
maysaslserver saslswitchchannel tcp_auth missingrecipientpolicy 0      \    
tcp_siroe-daemon

    新しいキーワードと値のペア pool SMTP_SIROE に注目してください。これは、このチャネルへのメッセージでは SMTP_SIROE プールのコンピュータリソースだけを使用するように指定しています。また、新しいチャネルの前後には空白行が必要です。

  2. imta.cnf ファイルの書き換えルールセクションに 2 つの書き換えルールを追加して、siroe.com 宛の電子メールをこの新しいチャネルに送信します。

    新しい書き換えルールは次のようになります。


    siroe.com     $U%$D@tcp_siroe-daemon
.siroe.com      $U%$H$D@tcp_siroe-daemon

    これらの書き換えルールは、(host1.siroe.com や hostA.host1.siroe.com などのアドレスも含む) siroe.com 宛のメッセージを、tcp_siroe-daemon という正式なホスト名を持つ新しいチャネルに送信します。これらのルールの書き換え部分 $U%$D および $U%$H$D は、メッセージの元のアドレスを保持します。$U は、元のアドレスからユーザー名をコピーします。% は区切り文字で、ユーザー名とドメインの間の @ です。$H は、パターン内のドットの左側にあるホスト/ドメイン指定のうち、一致しない部分をコピーします。$D は、ドメイン指定のうち、一致する部分をコピーします。

  3. SMTP_SIROE という新しいジョブコントローラプールを定義します。

    /msg_svr_base/config/job_controller.cnf に、次の内容を追加します。


    [POOL=SMTP_SIROE]
job_limit=10

    これは、最大 10 個のジョブを同時に実行できる SMTP_SIROE というメッセージリソースプールを作成します。このプール定義とほかのプール定義の間に空白行を入れないでください。ジョブおよびプールの詳細については、「ジョブコントローラ」を参照してください。

  4. MTA を再起動します。

    次のコマンドを発行します。imsimta refresh

    これは設定を再コンパイルし、ジョブコントローラとディスパッチャーを再起動します。

    この例では、内部ユーザーから大量の電子メールが siroe.com という特定のリモートサイト宛に送られます。何らかの理由で、siroe.com は一時的に、着信 SMTP 接続を受け入れることができず、電子メールを配信できない状態です。このような状況はまれなことではありません。

    siroe.com 宛の電子メールが届くと、配信できないメッセージで送信チャネルキュー (通常は tcp_local) がいっぱいになります。MTA はこれらのメッセージの再配信を定期的に試行するので (再試行の頻度と回数は backoff キーワードで設定可能)、通常の状況では操作は必要ありません。

    ただし、多くのメッセージがキューに溜まると、siroe.com 宛のメッセージのバックログを処理するためにすべてのチャネルジョブが使用され、ほかのメッセージが適時に配信されなくなることがあります。このような場合は、独自のジョブコントローラプールで実行されている新しいチャネルに siroe.com 宛のメッセージを再ルーティングすることもできます (「ジョブコントローラ」を参照)。これによって、siroe.com 宛のメッセージで使用されている処理リソースの競合が回避され、ほかのチャネルはそれぞれのメッセージを配信できるようになります。次に、新しいチャネルを作成してこの状況に対処する手順を説明します。

MTA メッセージが配信されない

メッセージ転送に関する問題のほかに、2 つの一般的な問題があります。この問題はメッセージキューにある未処理のメッセージに起因することがあります。

  1. キューキャッシュはキューディレクトリにあるメッセージと同期しません。MTA キューサブディレクトリにある配信待ちのメッセージファイルは、メモリー内キューキャッシュに入れられます。起動時にチャネルプログラムは、このキューキャッシュを調べて、キューにあるどのメッセージを配信するかを確認します。メッセージファイルがキューの中にあっても、対応するキューキャッシュエントリがない場合もあります。

    1. 特定のファイルがキューキャッシュにあるかどうかをチェックするには、imsimta cache -view ユーティリティーを使用します。ファイルがキューキャッシュにない場合は、キューキャッシュを同期させる必要があります。

      キューキャッシュは、通常は 4 時間ごとに同期されます。必要に応じて、imsimta cache -sync を使用してキャッシュを手動で再同期することができます。同期が終わると、チャネルプログラムは、新しいメッセージが処理されたあとで、元の未処理メッセージを処理します。デフォルト (4 時間) を変更する場合は、sync_time= timeperiod を追加することで、ディレクトリ /msg_svr_base/config にある job_controller.cnf ファイルを変更する必要があります。ここで、timeperiod は、キューキャッシュを同期させる頻度です。timeperiod は 30 分より長くする必要があります。次の例では、job_controller.cnf のグローバルなデフォルト (Global defaults) を指定するセクションに sync_time=02:00 を追加することで、キューキャッシュの同期間隔が 2 時間に変更されます。


      ! VERSION=5.0
!IMTA job controller configuration file
!
!Global defaults
tcp_port=27442
secret=N1Y9[HzQKW
slave_command=NULL
sync_time=02:00

      imsimta cache -sync を実行したあとに、imsimta submit channel を実行してメッセージのバックログを空にすることができます。メッセージのバックログが大きい (1000 以上) 場合、チャネルを空にするのに時間がかかることがあるので、注意してください。

      キューキャッシュの情報の概要については、imsimta qm -maint dir -database -total を実行してください。

    2. キューキャッシュを同期させてもメッセージがまだ配信されない場合は、ジョブコントローラを再起動する必要があります。これを行うには、imsimta restart job_controller コマンドを使用します。

      ジョブコントローラを再起動すると、メッセージのデータ構造がディスク上のメッセージキューから再構築されます。

      注意 – 注意 –

      ジョブコントローラの再起動は最後の手段です。ほかの手段をすべて使用し尽くすまでは実行しないでください。

      ジョブコントローラの詳細については、「ジョブコントローラ」を参照してください。

  2. 処理するログファイルを作成できないために、チャネル処理プログラムの実行は失敗します。アクセス権、ディスク容量、および制限容量をチェックします。

メッセージがループしている

メッセージがループしていることをMTA が検出すると、そのメッセージは .HELD ファイルとして保持されます。詳細については、「.HELD メッセージを診断して整理する」を参照してください。場合によっては、MTA がメッセージループを検出できないときもあります。

最初のステップは、メッセージがループしている理由を確認することです。問題のメッセージのコピー (MTA キュー領域にあるとき)、問題のメッセージに関連する MTA メールログエントリ (該当チャネルの MTA 設定ファイルで logging チャネルキーワードが有効になっている場合)、および該当チャネルの MTA チャネルのデバッグログファイルを確認します。問題のメッセージの From: および To: アドレス、Received: ヘッダー行、およびメッセージ構造 (メッセージ内容のカプセル化の種類) を確認して、発生したメッセージループの種類を特定することができます。

一般的によくある原因として、以下のものがあります。

  1. ポストマスターアドレスが壊れている。

    MTA では、電子メールを受信するために、ポストマスターアドレスが正しく機能しなければなりません。ポストマスターへのメッセージがループしている場合は、メッセージを受信できるアカウントをポイントする適切なポストマスターアドレスが設定されているかどうかチェックします。

  2. Received: ヘッダー行の削除が、MTA によるメッセージループの検出の妨げとなっている。

    通常のメッセージループの検出は、Received: ヘッダー行に基づいています。Received: ヘッダー行が MTA システム自体で明示的に、あるいはファイアウォールのような別のシステム上で削除されている場合、メッセージループを適切に検出できなくなることがあります。このような場合は、Received: ヘッダー行が知らないうちに削除されていないかどうかチェックします。また、メッセージがループしている根本的な原因もチェックします。考えられる原因は、システム名の割り当ての問題 (システムが自分の名前の変形を認識しないように設定されている場合)、DNS の問題、該当するシステムに承認可能なアドレス情報がないこと、あるいはユーザーアドレス転送エラーなどです。

  3. ほかのメッセージングシステムによる通知メッセージの処理が正しくなく、通知メッセージに応答して再度カプセル化されたメッセージが生成されています。

    インターネット規格では、通知メッセージ (メッセージ配信やメッセージバウンスのレポート) にメッセージループを防ぐための空のエンベロープ From: アドレスがあることを必要としています。ただし、メッセージングシステムによってはこのような通知メッセージを正しく処理しない場合もあります。このようなメッセージングシステムは、通知メッセージを転送またはバウンスするときに、新しいエンベロープ From: アドレスを挿入することがあります。これがメッセージループの原因になることもあります。解決策は、通知メッセージを正しく処理していないメッセージングシステムを修復することです。

.HELD メッセージを診断して整理する

メッセージがサーバーまたはチャネル間でバウンスされていることを MTA が検出すると、配信は停止され、メッセージは /msg_svr_base/data/queue/channel にある、サフィックスが .HELD のファイルに格納されます。通常、メッセージのループが発生するのは、各サーバーまたはチャネルがメッセージの配信をほかのサーバーやチャネルが担当するとみなしたときです。

たとえば、エンドユーザーが、2 つの別々のメールホスト上のメッセージを互いのホストに転送するオプションを設定しているとします。sesta.com アカウントに対して、varrius.com アカウントへのメール転送を有効にしています。また、この設定が有効であることを忘れて、varrius.com アカウントに対して sesta.com アカウントへのメール転送を有効にしています。

ループは、MTA の設定に誤りがあるために発生することもあります。たとえば、MTA ホスト X は、mail.sesta.com のメッセージがホスト Y に送信されるとみなします。しかし、ホスト Y はホスト X が mail.sesta.com のメッセージを処理すべきとみなし、結果としてホスト Y はホスト X にメールを返信することになります。

このような場合、MTA はメッセージを無視し、それ以上配信は試行されません。このような問題が発生したときは、メッセージ内のヘッダー行を見て、サーバーまたはチャネルがメッセージをバウンスしているかどうか確認します。必要であればエントリを修正してください。

imsimta qm release を実行するか、または次の手順に従って .HELD メッセージを再試行することもできます。

  1. 拡張子 .HELD を 00 以外の任意の 2 桁の数字 (たとえば、06) に変更します。

    注 –

    .HELD ファイルの名前を変更する前に、メッセージのループが停止していることを確認してください。

  2. imsimta cache -sync を実行します。このコマンドを実行すると、キャッシュが更新されます。

  3. imsimta submit channel または imsimta run channel を実行します。

これらの手順は何回か実行することが必要かもしれません。これは、Received: ヘッダー行が蓄積され、それによってメッセージに再度 .HELD とマークが付けられている可能性があるためです。

受信したメッセージがエンコードされている

MTA が送信したメッセージは、エンコードされた形式で受信されます。次に例を示します。

Date: Wed, 04 Jul 2001 11:59:56 -0700 (PDT)
From: "Desdemona Vilalobos" <Desdemona@sesta.com> 
To: santosh@varrius.com
Subject: test message with 8bit data 
MIME-Version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Content-transfer-encoding: QUOTED-PRINTABLE

2=00So are the Bo=F6tes Void and the Coal Sack the same?=

これらのメッセージは、MTA デコーダコマンド imsimta decode を使用すれば、デコードされて表示されます。詳細については、『Sun Java System Messaging Server Administration Reference』を参照してください。

RFC 821 で定義されているように、SMTP プロトコルで送信できるのは ASCII 文字 (7 ビット文字セット) のみです。実際、ネゴシエーションが行われていない 8 ビット文字の転送は SMTP 経由では無効であり、いくつかの SMTP サーバーでさまざまな問題の原因になることがあります。たとえば、SMTP サーバーが計算量の多いループに陥ってしまうことがあります。メッセージは何度も繰り返し送信されます。8 ビット文字は SMTP サーバーをクラッシュさせることがあります。最終的に、8 ビット文字セットは、8 ビットデータを扱えないブラウザやメールボックスに大きな損害をもたらす可能性があります。

以前に使用されていた SMTP クライアントには、8 ビットデータを含むメッセージを処理するときのオプションが 3 つしかありませんでした。メッセージを配信不能として差出人に返送するオプション、メッセージをエンコードするオプション、RFC 821 の直接違反でメッセージを送信するオプションです。しかし、MIME および SMTP 拡張の出現により、現在では、ASCII 文字セットを使用することによって 8 ビットデータをエンコードする標準のエンコーディングがあります。

前述の例で受取人は、MIME コンテンツタイプが TEXT/PLAIN のエンコードされたメッセージを受信しています。リモート SMTP サーバー (MTA SMTP クライアントからのメッセージの転送先) は、8 ビットデータの転送をサポートしていません。元のメッセージに 8 ビット文字が含まれていたため、MTA はメッセージをエンコードする必要があります。

SSR (Server-Side Rules) が作動していない

フィルタは、メールメッセージに適用される 1 つ以上の条件付きアクションで構成されています。フィルタはサーバー上に保存されて評価されるため、SSR (Server-Side Rule) と呼ばれることがよくあります。

この節では、SSR に関する次の情報について説明します。

「ユーザーレベルのフィルタをデバッグするには」も参照してください。

SSR ルールをテストする


# imsimta test -rewrite -debug -filter user@domain

出力では次の情報を探します。


mmc_open_url called to open ssrf:user@ims-ms
   URL with quotes stripped: ssrd: user@ims-ms
Determined to be a SSRD URL.
   Identifier: user@ims-ms-daemon
Filter successfully obtained.

一般的な構文の問題

ユーザーが電子メールの送信ボタンを押したときの応答が遅い

ユーザーがメッセージを送信するときに遅延がある場合は、メッセージキューディスクのサイズ不足が原因でディスクの入出力が低下している可能性があります。ユーザーが電子メールクライアントの送信ボタンを押したとき、メッセージキューへのメッセージのコミットが完了するまで、MTA はメッセージの受信確認を完全には受け入れません。メッセージキューのサイズ設定については、『』を参照してください。

アドレスのローカル部分または受信フィールド内のアスタリスク

MTA は、アドレスのローカル部分および作成する受信フィールド内の ASCII 文字のみではなく 8 ビット文字もチェックし、アスタリスクで置き換えるようになりました。

一般的なエラーメッセージ

MTA が起動に失敗すると、コマンド行に一般的なエラーメッセージが表示されます。この節では、共通の一般的なエラーメッセージの説明と診断を示します。

注 –

MTA 設定を診断するには、imsimta test -rewrite -debug ユーティリティーを使用して MTA のアドレス書き換えとチャネルマッピング処理を調べます。このユーティリティーを使用すれば、メッセージを実際に送信しなくても設定をチェックすることができます。詳細については、「MTA 設定をチェックする」を参照してください。

MTA サブコンポーネントは、この章では説明していないほかのエラーメッセージを発行することもあります。各サブコンポーネントの詳細については、『 Sun Java System Messaging Server Administration Reference』の MTA コマンド行ユーティリティーおよび設定の章と、第 5 章から第 10 章を参照してください。ここでは、次のタイプのエラーについて説明します。

mm_init でのエラー

mm_init でのエラーは、通常は MTA の設定の問題を示します。imsimta test -rewrite ユーティリティーを実行する場合は、これらのエラーが表示されます。imsimta cnbuild などのその他のユーティリティー、チャネル、サーバー、またはブラウザがこのようなエラーを返すこともあります。

よく発生する mm_init エラーには以下のものがあります。

bad equivalence for alias. . .

エイリアスファイルのエントリの右側が適切にフォーマットされていません。

cannot open alias include file. . .

エイリアスファイルに含まれているファイルを開くことができません。

duplicate aliases found. . .

エイリアスファイルの 2 つのエントリで、左側が同じになっています。重複するものを見つけて削除する必要があります。error line #XXX というエラーメッセージを探します。XXX は行番号です。この行にある重複のエイリアスを修正することができます。

duplicate host in channel table. . .

このエラーメッセージは、MTA の設定に 2 つのチャネル定義があり、両方に同じ正規ホスト名があることを示しています。

MTA 設定ファイル (imta.cnf) の書き換えルール (上部) に関係のない空白行があると、MTA は設定ファイルの残りの部分をチャネル定義と解釈します。ファイルの最初の行が空白でないことを確認してください。同じパターンを持つ書き換えルール (左側) が複数あると、MTA はそれらの書き換えルールを、一意でない正規のホスト名を含むチャネル定義と解釈します。正規のホスト名が重複しているチャネル定義がないかどうか、また、ファイル上部 (書き換えルールの部分) に不適切な空白行がないかどうか、MTA の設定をチェックしてください。

duplicate mapping name found. . .

このメッセージは、2 つのマッピングテーブルに同じ名前が付いていて、これらの重複するマッピングテーブルのいずれかを削除する必要があることを示します。ただし、マッピングファイル内のフォーマットエラーによって、MTA が何かを間違ってマッピングテーブル名と解釈することもあります。たとえば、マッピングテーブルエントリが適切にインデントされていないと、MTA はエントリの左側が実際にマッピングテーブル名であるとみなします。マッピングファイルが一般の形式であることと、マッピングテーブル名をチェックしてください。

注 –

空白行はマッピングテーブル名を含む行の前と後ろに付ける必要があります。ただし、空白行をマッピングテーブルのエントリ間に入れないでください。

mapping name is too long. . .

このエラーは、マッピングテーブル名が長すぎるので、短くする必要があることを示しています。マッピングファイル内のフォーマットエラーによって、MTA が何かを間違ってマッピングテーブル名と解釈することもあります。たとえば、マッピングテーブルエントリが適切にインデントされていないと、MTA はエントリの左側が実際にマッピングテーブル名であるとみなします。マッピングファイルとマッピングファイル名をチェックしてください。

error initializing ch_ facility compiled character set version mismatch

このメッセージが表示された場合は、imsimta chbuild. コマンドを使用して、コンパイル済みの文字セットテーブルを再コンパイルして再インストールする必要があります。詳細は、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「imsimta chbuild」を参照してください。

error initializing ch_ facility no room in. . .

通常、このエラーメッセージは、MTA 文字セットの内部テーブルのサイズを変更し、次のコマンドでコンパイル済み文字セットテーブルを再構築する必要があることを意味しています。


imsimta chbuild -noimage -maximum -option
imsimta chbuild

この変更を加える前に、ほかには何も再コンパイルまたは再起動する必要がないことを確認してください。imsimta chbuild の詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「imsimta chbuild」を参照してください。

local host alias or proper name too long for system. . .

このエラーは、ローカルホストエイリアスまたは固有名詞が長すぎることを示します (オプションで、チャネルブロックの 2 番目以降の名前の右側にある)。ただし、MTA 設定ファイル内でこのエラーより前に構文エラー (書き換えルールに関係のない空白行がある場合など) がある場合は、MTA が何かを間違ってチャネル定義と解釈することもあります。設定ファイルの指定されている行をチェックするだけでなく、その行より上にほかの構文エラーがないかどうかもチェックしてください。特に、このエラーが発生した行が書き換えルールを意図する行である場合は、その行より上に関係のない空白行がないかどうかを必ずチェックしてください。

no equivalence addresses for alias. . .

エイリアスファイル内のエントリの右側 (変換値) がありません。

no official host name for channel. . .

このエラーは、チャネル定義ブロックに必須の 2 番目の行 (正規のホスト名の行) がないことを示しています。チャネル定義ブロックの詳細については、『 Sun Java System Messaging Server Administration Reference』の MTA の設定およびコマンド行ユーティリティーの章と、第 12 章「チャネル定義を設定する」を参照してください。それぞれのチャネル定義ブロックの前と後ろには空白行が必要ですが、空白行をチャネル定義のチャネル名と正規のホスト名の行の間に入れることはできません。また、空白行は MTA 設定ファイルの書き換えルール部分には入れることはできません。

official host name is too long

チャネルの正規のホスト名 (チャネル定義ブロックの 2 行目) は、長さが 128 オクテットに制限されています。チャネル上で長めの正規ホスト名を使用しようとしている場合は、それをプレースホルダ名まで短くしてから、書き換えルールを使用してその長めの名前がその短い正規ホスト名に一致するようにします。このような状況は、l (ローカル) チャネルホスト名を使用しているときに起こることがあります。次に例を示します。


Original l Channel:
!ローカル /var/mail ストアへの配信チャネル
l subdirs 20 viaaliasrequired maxjobs 7 pool LOCAL_POOL
walleroo.pocofronitas.thisnameismuchtoolongandreallymakesnosensebutitisan
example.monkey.gorilla.orangutan.antidisestablismentarianism.newt.salaman
der.lizard.gecko.komododragon.com

Create Place Holder:
!ローカル /var/mail ストアへの配信チャネル 
l subdirs 20 viaaliasrequired maxjobs 7 pool LOCAL_POOL
newt

Create Rewrite Rule:
newt.salamander.lizard.gecko.komododragon.com   $U%$D@newt

l (ローカル) チャネルを使用しているときは、REVERSE マッピングテーブルを使用する必要があります。使用法と構文の詳細については、『Sun Java System Messaging Server Administration Reference』の MTA 設定の章を参照してください。

MTA 設定ファイル内でこのエラーより前に構文エラー (書き換えルールに関係のない空白行があった場合など) がある場合は、MTA が何かを間違ってチャネル定義と解釈することもあります。このため、書き換えルールを意図していたとしても、正規のホスト名と解釈されてしまうことがあります。設定ファイルの指定されている行をチェックするだけでなく、その行より上にほかの構文エラーがないかどうかもチェックしてください。特に、このエラーが発生した行が書き換えルールを意図する行である場合は、その行より上に関係のない空白行がないかどうかを必ずチェックしてください。

コンパイル済み設定のバージョンが一致していない

imsimta cnbuild ユーティリティーの機能の 1 つとして、MTA の設定情報を、すばやく読み込むことができるイメージにコンパイルする機能があります。コンパイル済みフォーマットは厳密に定義されており、多くの場合、異なるバージョンの MTA 間では実質的に異なっています。小さな変更はパッチリリースとして発生することもあります。

このような変更が発生すると、互換性のないフォーマットを検出するために、内部バージョンフィールドも変更されます。互換性のないフォーマットを検出すると、MTA コンポーネントは上記のエラーで停止します。この問題の解決策は、imsimta cnbuild コマンドを使って新しいコンパイル済み設定を生成することです。

また、imsimta restart コマンドを使用して常駐 MTA サーバープロセスを再起動することも良い方法です。これによって、常駐 MTA サーバープロセスは更新された設定情報を取得することができます。

スワップ空間のエラー

適切な動作を保証するために、メッセージングシステム上に十分なスワップ空間を設定することが重要です。必要なスワップ空間の量は設定によって異なります。調整の際に一般的に推奨されるのは、スワップ空間の量を主記憶容量の少なくとも 3 倍にすることです。

次のようなエラーメッセージは、スワップ空間が不足していることを示しています。

jbc_channels: chan_execute [1]: fork failed: Not enough space

このエラーはジョブコントローラのログファイルで見られることがあります。その他のスワップ空間のエラーは設定によって異なります。

次のコマンドを使用して、スワップ空間の空き容量と使用容量を確認します。

ファイルのオープンまたは作成エラー

メッセージを送信するために、MTA は設定ファイルを読み取って、MTA メッセージキューディレクトリにメッセージファイルを作成します。設定ファイルは、MTA または MTA の SDK に対して書かれたプログラムが読み取ることのできるものでなければなりません。適切な権限はこれらのファイルのインストール中に割り当てられます。設定ファイルを作成する MTA ユーティリティーとプロシージャーも、権限を割り当てます。ファイルがシステムマネージャー、特権を持つほかのユーザー、またはサイト固有のプロシージャーによって保護されている場合、MTA は設定情報を読み取ることができない場合があります。その結果、「ファイルオープン」エラーや予測不能な動作が発生します。設定ファイルの読み取りに関する問題が発生したときは、imsimta test -rewrite ユーティリティーが追加情報をレポートします。詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「imsimta test」を参照してください。

MTA が、権限を持つアカウントから機能していて、権限のないアカウントからは機能していないように見える場合は、MTA テーブルディレクトリのファイルアクセス権が問題の原因と思われます。設定ファイルとそのディレクトリのアクセス権をチェックしてください。詳細については、「危険なファイルの所有権をチェックする」を参照してください。

「ファイル作成」エラーは、通常、MTA メッセージキューディレクトリにメッセージファイルを作成する際に問題が発生したことを示しています。ファイル作成に関する問題の診断については、「メッセージキューディレクトリをチェックする」を参照してください。

不正なホストまたはドメインエラー

このエラーは、ブラウザで MTA にアドレスを指定したときに見られることがあります。また、このエラーは、据え置かれて、エラー返送メールメッセージの一部として返送されることがあります。どちらの場合もこのエラーメッセージは、MTA が指定したホストにメールを配信できないことを示しています。メールが指定したホストに送信されていない原因を確認するには、以下のトラブルシューティング手順に従います。

SMTP チャネルでのエラー: os_smtp_* エラー

os_smtp_open、os_smtp_read、os_smtp_write などの os_smtp_* エラーは、必ずしも MTA エラーではありません。これらのエラーは、MTA がネットワーク層で発生した問題をレポートするときに生成されます。たとえば、os_smtp_open エラーは、リモート側へのネットワーク接続を開くことができなかったことを意味します。MTA は、アドレスエラーやチャネル設定エラーのために無効なシステムに接続するよう設定されていることがあります。一般的に os_smtp_* エラーは、DNS またはネットワーク接続の問題が原因です (特に、以前に動作していたチャネルやアドレスの場合)。os_smtp_read または os_smtp_write エラーは、一般的に、接続がリモート側で強制終了されたか、ネットワーク上の問題によるものであることを示しています。

多くの場合、ネットワークおよび DNS の問題は実際には一時的です。ときどき発生する os_smtp_* エラーは、通常は気にしなくても大丈夫です。ただし、これらのエラーが頻繁に表示される場合は、根本的なネットワーク上の問題がある可能性があります。

特定の os_smtp_* エラーに関する詳細情報を入手するには、該当するチャネル上でデバッグを有効にします。試行された SMTP ダイアログの詳細を示す、デバッグチャネルのログファイルを調べます。特に、ネットワークの問題が SMTP ダイアログのどこのタイミングで発生したかを確認します。このタイミングは、ネットワークまたはリモート側の問題の種類を示していることがあります。場合によっては、ネットワークレベルのデバッグ (たとえば、TCP/IP パケットトレース) を実行して、何を送信または受信したかを確認することもできます。