test

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

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 が自分の管理下にない場合は、問題を報告したユーザーが特定のサイトに問い合わせる必要があります。