Sun Java ロゴ     前へ      目次      索引      次へ     

Sun ロゴ
Sun Java System Messaging Server 6 2005Q1 管理ガイド 

第 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 Administration Reference』の MTA コマンド行ユーティリティの章を参照してください。

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

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

MTA メッセージキューディレクトリ (通常、msg_svr_base/data/queue/) にメッセージがあるかどうかをチェックします。希望するメッセージが MTA メッセージキューディレクトリにあるかどうかをチェックするには、imsimta qm のようなコマンド行ユーティリティを使用します。imsimta qm の詳細については、『Sun Java System Messaging Server Administration Reference』の 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 Administration Reference』を参照してください。

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

ログファイルが存在しないか、エラーが示されていない場合は、msg-start コマンドを使ってプロセスを開始してください。詳細は、『Sun Java System Messaging Server Administration Reference』の 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

配信に関する問題が発生した場合の ms-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 Administration Reference』の MTA コマンド行ユーティリティの章を参照してください。


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

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

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

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

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

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


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


msimta submit コマンドと imsimta run コマンドの構文、オプション、パラメータ、例の詳細については、『Sun Java System Messaging Server Administration Reference』の MTA コマンド行ユーティリティの章を参照してください。

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

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

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

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

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

imsimta qm start コマンドと imsimta qm stop コマンドの詳細については、『Sun Java System Messaging Server Administration Reference』の MTA コマンド行ユーティリティの章を参照してください。

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

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

ドメインまたは 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. メッセージが通過するチャネルを確認します。
  6. チャネルを識別する方法にはいろいろありますが、以下の方法をお勧めします。

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

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

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

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

  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 プラットフォームの例を見てください。
    2. # cp ZZ01K7LXW76T7O9TD0TB.00 ZZ01K7LXW76T7O9TD0TB.KEEP1

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

    3. メッセージが処理される順番を識別するために、メッセージをトラップしてコピーするたびに、メッセージの拡張子に番号を付けることをお勧めします。
  6. チャネルでメッセージの処理を再開し、メッセージのパスにある次の宛先チャネルのキューに入れます。これを行うには、imsimta qm start コマンドを使用します。
  7. /msg_svr_base/log ディレクトリにある対応するチャネルログファイル (たとえば、tcp_intranet_master.log-*) をコピーして、保存します。追跡しているメッセージのデータを含む該当するログファイルを選択します。必ず、コピーするファイルが、チャネルで受信するメッセージのタイムスタンプおよび Subject ヘッダーと一致するようにします。tcp_intranet_master.log-* の例では、ファイルが削除されないように、ファイルを tcp_intranet_master.keep という名前で保存しています。
  8. 最終的な宛先に達するまで、手順 5 〜 7 を繰り返します。
  9. 手順 7 でコピーしたログファイルは、手順 5 でコピーしたメッセージファイルと相互に関連させる必要があります。たとえば、メッセージ部分がないためにすべてのチャネルを停止した場合は、conversion_master.log-* ファイルと tcp_intranet_master.log-* ファイルを保存します。ソースチャネルのログファイル tcp_local_slave.log-* も保存します。さらに、それぞれの宛先チャネルの対応するメッセージファイルのコピーを保存します。つまり、conversion チャネルの ZZ01K7LXW76T7O9TD0TB.KEEP1tcp_intranet チャネルの ZZ01K7LXW76T7O9TD0TB.KEEP2 を保存します。

  10. メッセージとログファイルがコピーされたら、デバッグオプションを削除します。
    1. ディレクトリ /msg_svr_base/config 内の imta.cnf ファイルにある該当するチャネルから、slave_debug キーワードと master_debug キーワードを削除します。
    2. mm_debug=0 をリセットし、ディレクトリ/msg_svr_base/configoption.dat ファイルにある log_message_id=1 を削除します。
    3. imsimta cnbuild を使用して設定を再コンパイルします。
    4. imsimta restart dispatcher コマンドを実行して SMTP サーバーを再起動します。

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

  1. チャネルプログラムの起動と停止が終わるまでには、トラブルシューティングのために使用できる以下のファイルがあるはずです。
    1. 各チャネルプログラムのメッセージファイルのすべてのコピー (たとえば、ZZ01K7LXW76T7O9TD0TB.KEEP1)
    2. tcp_local_slave.log-* ファイル
    3. 各宛先チャネルの channel_master.log-* ファイルのセット
    4. メッセージのパスを示す mail.log_current レコードのセット
    5. すべてのファイルには、mail.log_current レコードにあるメッセージ ID: ヘッダー行に一致するタイムスタンプ値とメッセージ ID 値がある必要があります。メッセージが受取人にバウンスされた場合は例外です。バウンスされたメッセージには元のメッセージとは異なるメッセージ ID 値が付いています。

  2. tcp_local_slave.log-* ファイルを調べて、メッセージがキューに入れられたときにメッセージにメッセージ部分があったかどうかを確認します。
  3. SMTP ダイアログとデータを見て、クライアントマシンから何が送信されたかを確認します。

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

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

  6. メッセージの最終的な宛先を確認します。
  7. 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 インストールガイド』を参照してください。

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

ディスパッチャ (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 でアクセスすることはできません。

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

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

着信 SMTP 接続時のタイムアウトは、システムリソースやその割り当てに関連していることがよくあります。以下の方法を使用して、着信 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))

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

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

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

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

    hosts:dns nis [NOTFOUND=return] files

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

    hosts:dns nis [NOTFOUND=return] files

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

  6. 着信 SMTP over TCP/IP メールを処理しているチャネル (通常は、tcp_localtcp_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 リレーに接続する必要があります。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 ポートのテストを行う必要があります。


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

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

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

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

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

  1. キューキャッシュはキューディレクトリにあるメッセージと同期しません。MTA キューサブディレクトリにある配信待ちのメッセージファイルは、メモリ内キューキャッシュに入れられます。起動時にチャネルプログラムは、このキューキャッシュを調べて、キューにあるどのメッセージを配信するかを確認します。メッセージファイルがキューの中にあっても、対応するキューキャッシュエントリがない場合もあります。
    1. 特定のファイルがキューキャッシュにあるかどうかをチェックするには、imsimta cache -view ユーティリティを使用します。ファイルがキューキャッシュにない場合は、キューキャッシュを同期させる必要があります。
    2. キューキャッシュは、通常は 4 時間ごとに同期されます。必要に応じて、imsimta cache -sync を使用してキャッシュを手動で再同期することができます。同期が終わると、チャネルプログラムは、新しいメッセージが処理されたあとで、元の未処理メッセージを処理します。デフォルト (4 時間) を変更する場合は、sync_time=timeperiod を追加することで、ディレクトリ /msg_svr_base/config にある job_controller.cnf ファイルを変更する必要があります。ここで、timeperiod は、キューキャッシュを同期させる頻度です。timeperiod は 30 分より長くする必要があります。以下の例では、job_controller.cnf のデフォルトのグローバルセクションに sync_time=02:00 を追加することで、キューキャッシュの同期間隔が 2 時間に変更されます。

      ! VERSION=5.0
      !IMTA ジョブコントローラ設定ファイル
      !
      !グローバルデフォルト
      tcp_port=27442
      secret=N1Y9[HzQKW
      slave_command=NULL
      sync_time=02:00

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

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

    3. キューキャッシュを同期させてもメッセージがまだ配信されない場合は、ジョブコントローラを再起動する必要があります。これを行うには、imsimta restart job_controller コマンドを使用します。
    4. ジョブコントローラを再起動すると、メッセージのデータ構造がディスク上のメッセージキューから再構築されます。


      警告

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


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

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

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

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

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

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

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

  5. ほかのメッセージングシステムによる通知メッセージの処理が正しくなく、通知メッセージに応答して再度カプセル化されたメッセージが生成されています。
  6. インターネット規格では、通知メッセージ (メッセージ配信やメッセージバウンスのレポート) にメッセージループを防ぐための空のエンベロープ 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 で定義されているように、ASCII 文字 (7 ビット文字セット) を送信できるのは SMTP プロトコルのみです。実際には、ネゴシエーションが行われていない 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 Rules) と呼ばれることがよくあります。

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

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

SSR ルールをテストする

一般的な構文の問題

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

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 Administration Reference』を参照してください。

error initializing ch_ facility: no room in. . .

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

imsimta chbuild -noimage -maximum -option
imsimta chbuild

この変更を加える前に、ほかには何も再コンパイルまたは再起動する必要がないことを確認してください。imsimta chbuild の詳細については、『Sun Java System Messaging Server Administration Reference』の MTA コマンド行ユーティリティの章を参照してください。

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.thisnameismuchtoolongandreallymakesnosensebutiti sanexample.monkey.gorilla.orangutan.antidisestablismentarianism.newt.s alamander.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 Administration Reference』の MTA の章にある imsimta test -rewrite の説明を参照してください。

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 パケットトレース) を実行して、何を送信または受信したかを確認することもできます。



前へ      目次      索引      次へ     


Copyright 2005 Sun Microsystems, Inc. All rights reserved.