Sun Java System Messaging Server 6.3 管理ガイド

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

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

26.2.1 MTA 設定をチェックする

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

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

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

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

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

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

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

msg-svr-base/data/queue/
msg-svr-base/data/log
msg-svr-base/data/tmp

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

ls -l -p -d /opt/SUNWmsgsr/data/queue
drwxr-x---   2 mailsrv  mail 512 Jan  4 16:09 /opt/SUNWmsgsr/data/queue/

ls -l -p -d /opt/SUNWmsgsr/data/log
drwxr-x---   2 mailsrv  mail  3072 Feb 16 12:07 /opt/SUNWmsgsr/data/log/

ls -l -p -d /opt/SUNWmsgsr/data/tmp
drwxr-x---   2 mailsrv  mail   512 Feb 16 12:55 /opt/SUNWmsgsr/data/tmp/

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

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

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

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

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

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

# imsimta process
USER      PID S VSZ    RSS   STIME    TIME     COMMAND
mailsrv 9567 S 18416 9368  02:00:02  0:00  /opt/SUNWmsgsr/lib/tcp_smtp_server
mailsrv 6573 S 18112 5720  Jul_13    0:00  /opt/SUNWmsgsr/lib/job_controller
mailsrv 9568 S 18416 9432  02:00:02  0:00  /opt/SUNWmsgsr/lib/tcp_smtp_server
mailsrv 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.3 Administration Reference』の「imsimta process」を参照してください。

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

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

注 –

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

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

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

表 26–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 コマンドを使用して、古いログファイルを消去することもできます。ただし、このコマンドはデフォルトで定期的に実行されます (「4.6.2 定義済みの自動タスク」を参照)。詳細は、『Sun Java System Messaging Server 6.3 Administration Reference』の「imsimta purge」の MTA コマンド行ユーティリティーの章を参照してください。

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

現在の設定にエラーがある場合。
master_debug または slave_debug キーワードが imta.cnf ファイル内のチャネルに設定されている場合。
mm_debug が option.dat ファイルでゼロ以外の値 (mm_debug > 0) に設定されている場合。option.dat ファイルは /msg-svr-base/config/ にあります。

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

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

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

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

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

注 –

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

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

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

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

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

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

imsimta qm stop conversion

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

imsimta qm start conversion

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

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

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

特定のホストまたはドメイン名からの受信処理を停止するには、MTA マッピングファイル (通常は /msg-svr-base/config/mappings) にある ORIG_SEND_ACCESS マッピングテーブルに次のアクセスルールを追加します。

ORIG_SEND_ACCESS 

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

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

特定の IP アドレスからの受信処理を停止するには、MTA マッピングファイル (通常は /msg-svr-base/config/mappings) にある PORT_ACCESS マッピングテーブルに次のアクセスルールを追加します。

PORT_ACCESS

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

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

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

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

注 –

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

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

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

ディレクトリ /msg-svr-base/config にある option.dat ファイルに log_message_id=1 を追加します。このパラメータにより、メッセージ ID: ヘッダー行が mail.log_current ファイルに表示されます。
imsimta cnbuild を実行して設定を再コンパイルします。
imsimta restart dispatcher を実行して、SMTP サーバーを再起動します。
エンドユーザーにメッセージ部分を含むメッセージを再送信してもらいます。
メッセージが通過するチャネルを確認します。

チャネルを識別する方法にはいろいろありますが、次の方法をお勧めします。
1. UNIX プラットフォームの場合は、grep コマンドを使用して、メッセージ ID: ヘッダー行を /msg-svr-base/log ディレクトリにある mail.log_current ファイルで検索します。
2. メッセージ ID: ヘッダー行が見つかったら、E (キューに入れる) および D (キューから取り出す) レコードを検索して、メッセージのパスを確認します。ログエントリコードの詳細については、「25.3.1 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 チャネルに移っていることを示しています。

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

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

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

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

ディレクトリ /msg-svr-base/config 内の imta.cnf ファイルにある該当するチャネルに、slave_debug キーワードと master_debug キーワードを追加します。
1. リモートシステムから送信されるメッセージ部分を含むメッセージの受信チャネル (または最初のダイアログの間にメッセージが切り替えられるチャネル) で、slave_debug キーワードを使用します。この例では、slave_debug キーワードが tcp_local チャネルに追加されています。
2. メッセージが通過し、「26.2.8.1 メッセージパスにあるチャネルを識別する」で識別されたほかのチャネルに、master_debug キーワードを追加します。この例では、master_debug キーワードは conversion チャネルと tcp_intranet チャネルに追加されます。
3. imsimta restart dispatcher コマンドを実行して SMTP サーバーを再起動します。

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

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

メッセージがチャネルに入るときに、メッセージが 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. メッセージが処理される順番を識別するために、メッセージをトラップしてコピーするたびに、メッセージの拡張子に番号を付けることをお勧めします。

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

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

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

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

メッセージとログファイルがコピーされたら、デバッグオプションを削除します。
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 サーバーを再起動します。

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

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

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

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

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

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

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

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

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

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