前へ
目次
索引
DocHome
次へ
|
| iPlanet Messaging Server 5.2 管理者ガイド |
第 14 章 MTA のトラブルシューティング
この章では、MTA (Message Transfer Agent) のトラブルシューティングのための一般的なツール、方法、手順について説明します。この章には、以下の節があります。
「トラブルシューティングの概要」
モニタ手順に関連する項目は、第 15 章「iPlanet Messaging Server をモニタする」で参照できます。
注 この章を読む前に、このマニュアルの第 6 章から第 10 章と、『iPlanet Messaging Server リファレンスマニュアル』の MTA 設定およびコマンドラインユーティリティに関する章をもう一度確認してください。
トラブルシューティングの概要
MTA トラブルシューティングの最初の段階の 1 つは、診断を始める場所を決めることです。該当する問題によって、ログファイルにあるエラーメッセージを検索することもできます。また、標準 MTA プロセスのすべてをチェックしたり、MTA 設定を見直したり、個々のチャネルを起動して停止することもできます。どの方法を使用する場合も、MTA のトラブルシューティングを行う際は次の点を考慮してください。
メッセージの受け入れが設定や環境に関する問題 (たとえば、ディスク容量や制限容量の問題) によって妨げられていないか ?
この章の以下の節で、これらの問題に対する処置を説明しています。メッセージがキューに入れられたときに、ディスパッチャやジョブコントローラなどの MTA サービスが実行されていたか ?
MTA のトラブルシューティングの標準的な手順
この節では、MTA のトラブルシューティングの標準的な手順の概要を説明します。問題が発生してもエラーメッセージが生成されない場合、エラーメッセージに十分な診断情報がない場合、あるいは MTA の全般的な状況のチェック、テスト、および標準的な保守を行う場合は、以下の手順に従ってください。
「MTA 設定をチェックする」
MTA 設定をチェックする
imsimta test -rewrite ユーティリティを使って、アドレス設定をテストしてください。このユーティリティを使うと、実際にメッセージを送信することなく、MTA のアドレス書き換えとチャネルマッピングをテストすることができます。詳細については、『iPlanet Messaging Server リファレンスマニュアル』の MTA コマンドラインユーティリティの章を参照してください。通常このユーティリティは、メッセージをキューに入れるチャネルとともに、適用されるアドレス書き換えを表示します。ただし、このユーティリティは、MTA 設定のシンタックスエラーが発生すると、エラーメッセージを発行します。出力が希望するものでない場合は、設定を修正することもできます。
メッセージキューディレクトリをチェックする
メッセージが MTA メッセージキューディレクトリ (通常は /server-root/msg-instance/imta/queue/) にあるかどうかをチェックしてください。希望するメッセージが MTA メッセージキューディレクトリにあるかどうかをチェックするには、imsimta qm のようなコマンドラインユーティリティを使用します。imsimta qm の詳細については、『iPlanet Messaging Server リファレンスマニュアル』と「imsimta qm counters」とを参照してください。imsimta test -rewrite の出力が正しいようであれば、メッセージが実際に MTA メッセージキューサブディレクトリに置かれているかどうかをチェックします。これを行うには、メッセージのログを有効にします (MTA ログの詳細は、「第 3 部 : サービスログ (MTA)」を参照)。次に、ディレクトリ /server-root/msg-instance/log/imta/ にある mail.log_current ファイルを調べます。特定のメッセージをそのメッセージ ID で追跡して、メッセージが MTA メッセージキューサブルーチンに置かれていることを確認できます。メッセージが見つからない場合は、ファイルのディスク容量やディレクトリアクセス権に関する問題がある可能性があります。
危険なファイルの所有権をチェックする
iPlanet Messaging Server をインストールしたときに、メールサーバのユーザアカウント (デフォルトでは nobody) を選択したはずです。以下のディレクトリ、サブディレクトリ、およびファイルは、このアカウントが所有している必要があります。/server-root/msg-instance/imta/queue/
/server-root/msg-instance/log/imta/
/service-root/msg-instance/imta/tmp以下の UNIX システムのコマンド例にあるようなコマンドを使用して、これらのディレクトリの保護と所有権をチェックできます。
以下の UNIX システムのコマンド例のようなコマンドを使用して、/server-root/msg-instance/imta/queue にあるファイルが MTA アカウントによって所有されていることをチェックします。
ls -l -p -R /usr/iplanet/server5/msg-budgie/imta/queue
ジョブコントローラとディスパッチャが実行中であることをチェックする
MTA ジョブコントローラは、大半の送信 (マスター) チャネルジョブなどの、MTA が処理するジョブの実行を行います。MTA チャネルの中には、MTA のマルチスレッド SMTP チャネルのように、受信メッセージを処理する常駐サーバプロセスを含むものもあります。このようなサーバは、チャネルのスレーブ (受信) 方向を扱います。MTA ディスパッチャは、そのような MTA サーバの作成を行います。ディスパッチャの設定オプションは、サーバの可用性、作成されたサーバの数、各サーバが処理できる接続の数を制御します。
ジョブコントローラとディスパッチャがあるかどうかをチェックし、MTA サーバと処理するジョブが実行中かどうかを確認するには、imsimta process コマンドを使用します。このコマンドは、アイドル状態では job_controller および dispatcher プロセスになります。たとえば、以下のようになります。
ジョブコントローラがない場合、/server-root/msg-instance/imta/queue ディレクトリにあるファイルはバックアップされ、メッセージは配信されません。ディスパッチャがなければ、SMTP 接続を受信することはできません。
imsimta process の詳細は、『iPlanet Messaging Server リファレンスマニュアル』を参照してください。
ジョブコントローラもディスパッチャもない場合は、/server-root/msg-instance/log/imta/ ディレクトリにある dispatcher.log-* または job_controller.log-* ファイルを確認します。
ログファイルが存在しないか、エラーが示されていない場合は、imsimta start コマンドを使ってプロセスを開始してください。詳細は、『iPlanet Messaging Server リファレンスマニュアル』の MTA コマンドラインユーティリティの章を参照してください。
注 imsimta process を実行するときは、ディスパッチャまたはジョブコントローラの複数のインスタンスが実行されていないようにしてください。
ログファイルをチェックする
MTA が処理するジョブが正常に実行されていても、メッセージがメッセージキューディレクトリに残っている場合は、ログファイルを調べて何が起きているかを見ることができます。すべての MTA ログファイルはディレクトリ /server-root/msg-instance/log/imta 内に作成されています。表 14-1 に、MTA が処理するさまざまなジョブのログファイル名の形式を示します。
channel_master.log-uniqueid およびchannel_slave.log-uniqueid のログファイルは、次のような状況で作成されます。
現在の設定にエラーがある場合。
チャネルのマスターおよびスレーブプログラムのデバッグについては、『iPlanet Messaging Server リファレンスマニュアル』を参照してください。master_debug または slave_debug キーワードが imta.cnf ファイル内のチャネルに設定されている場合。
mm_debug が option.dat ファイル (/server-root/msg-instance/imta/config/ ディレクトリ内) でゼロ以外の値 (mm_debug > 0) に設定されている場合。
チャネルプログラムを手動で実行する
MTA の配信問題を診断するときは、特に、1 つ以上のチャネルに対するデバッグを有効にしたあとで、MTA 配信ジョブを手動で実行することをお勧めします。imsimta submit コマンドは、MTA ジョブコントローラにチャネルの実行を通知します。問題のチャネルに対してデバッグが有効になっている場合は、表 14-1 で示すように、imsimta submit でディレクトリ /server-root/msg-instance/log/imta 内にログファイルが作成されます。
imsimta run コマンドは、現在アクティブなプロセスのもとでチャネルに対する送信を実行し、また、端末に出力を送信します。ジョブの送信自体に問題があると思われる場合は特に、ジョブを送信するよりもこの方法をお勧めします。
注
imsimta submit コマンドと imsimta run コマンドのシンタックス、オプション、パラメータ、例の詳細は、『iPlanet Messaging Server リファレンスマニュアル』の MTA コマンドラインユーティリティの章を参照してください。
個々のチャネルを起動および停止する
場合によっては、個々のチャネルを停止して再起動することで、メッセージキューの問題の診断とデバッグが行いやすくなることもあります。メッセージキューを停止して、キューに入れられたメッセージを検査し、ループまたはスパム攻撃があるかどうかを確認することができます。
特定のチャネルへの送信処理 (キューからの取り出し) を停止するには
imsimta qm stop コマンドを使用して、特定のチャネルを停止します。これにより、ジョブコントローラを停止する必要がなくなり、設定を再コンパイルしなくてすみます。以下の例では、conversion チャネルを停止しています。
imsimta qm start コマンドと imsimta qm stop コマンドの詳細は、『iPlanet Messaging Server リファレンスマニュアル』の MTA コマンドラインユーティリティの章を参照してください。
処理を再開するには、imsimta qm start コマンドを使用してチャネルを再起動します。以下の例では、conversion チャネルを再起動しています。
- imsimta qm stop conversion
- imsimta qm start conversion
特定のドメインまたは IP アドレスからの受信処理 (チャネルのキューに入れる) を停止するには
クライアントホストに一時的な SMTP エラーを返している間に、特定のドメインまたは IP アドレスからの受信メッセージ処理を停止したい場合は、以下の操作のいずれかを実行することができます。これを実行すると、メッセージはシステム上に保持されることはありません。「第 1 部 マッピングテーブル」を参照してください。
特定のホストまたはドメイン名からの受信処理を停止するには、MTA マッピングファイル (通常は /server-root/msg-instance/imta/config/mappings) にある ORIG_SEND_ACCESS マッピングテーブルに以下のアクセス規則を追加します。
ドメインまたは IP アドレスからの受信処理を再開するときは、必ず上記の規則をマッピングテーブルから削除し、設定を再コンパイルしてください。さらに、各マッピングテーブルごとに固有のエラーメッセージを作成することもできます。これを行うことで、使用中のマッピングテーブルを確認することができます。
ORIG_SEND_ACCESS
*|*@sesta.com|*|* $X4.2.1|$NHost$ blocked
特定の IP アドレスからの受信処理を停止するには、MTA マッピングファイル (通常は /server-root/msg-instance/imta/config/mappings) にある PORT_ACCESS マッピングテーブルに以下のアクセス規則を追加します。
- このようにすると、差出人のリモート MTA はメッセージをシステム上に保持し、受信処理を再開するまで定期的にそのメッセージを再送信し続けるようになります。
PORT_ACCESS
TCP|*|25|IP_address_to_block|* $N500$ unable$ to$ ¥
connect$ at$ this$ time
MTA のトラブルシューティングの例
この節では、特定の MTA の問題のトラブルシューティング方法をステップバイステップで説明します。この例では、メールの受取人は電子メールメッセージの添付ファイルを受信しませんでした。注 : MIME プロトコルの用語に沿って、この節では「添付ファイル」のことを「メッセージ部分」と呼びます。前述のトラブルシューティング方法を使用して、メッセージ部分が見えなくなった場所と原因を確認します (「MTA のトラブルシューティングの標準的な手順」を参照)。以下のステップで、メッセージが MTA を通じてとるパスを確認することができます。さらに、メッセージ部分が見えなくなったのがキューに入れられる前後かどうかを確認することができます。これを行うには、関連ファイルを取り込みながら、チャネルを手動で停止してから起動する必要があります。
注
メッセージパスにあるチャネルを識別する
メッセージパスにあるチャネルを識別することによって、該当するチャネルに master_debug および slave_debug キーワードを適用することができます。これらのキーワードはチャネルのマスターおよびスレーブログファイルにデバッグ出力を生成します。そのマスターおよびスレーブデバッグ情報により、メッセージ部分が見えなくなった場所が識別しやすくなります。
ディレクトリ /server-root/msg-instance/imta/config にある option.dat ファイルに log_message_id=1 を追加します。このパラメータにより、mail.log_current ファイルにあるメッセージ ID: ヘッダー行が表示されます。
imsimta cnbuild を実行して設定を再コンパイルします。
imsimta restart dispatcher を実行して、SMTP サーバを再起動します。
エンドユーザにメッセージ部分を含むメッセージを再送信してもらいます。
- チャネルを識別する方法にはいろいろありますが、以下の方法をお勧めします。
UNIX プラットフォームの場合は、grep コマンドを使用して、/server-root/msg-instance/log/imta/ ディレクトリにある mail.log_current ファイルでメッセージ ID: ヘッダー行を検索します。Windows NT プラットフォームの場合は、find コマンドを使用します。
メッセージ 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 プロセスのさまざまな段階で保存することができます。これらのファイルは、後述の 「メッセージに問題が発生した場所を確認する」の節で使用できます。
十分なデバッグ情報を提供するためには、ディレクトリ /server-root/msg-instance/imta/config にある option.dat ファイルに mm_debug=5 を設定します。
ディレクトリ /server-root/msg-instance/imta/config 内の imta.cnf ファイルにある該当するチャネルに、slave_debug キーワードと master_debug キーワードを追加します。
リモートシステムから送信されるメッセージ部分を含むメッセージの受信チャネル (または最初のダイアログの間にメッセージが切り替えられるチャネル) で、slave_debug キーワードを使用します。この例では、slave_debug キーワードが tcp_local チャネルに追加されています。
imsimta qm stop コマンドと imsimta qm start コマンドを使用して、特定のチャネルを起動して停止します。これらのキーワードの使用の詳細は、「個々のチャネルを起動および停止する」を参照してください。メッセージが通過し、「メッセージパスにあるチャネルを識別する」で識別されたほかのチャネルに、master_debug キーワードを追加します。この例では、master_debug キーワードは conversion チャネルと tcp_intranet チャネルに追加されます。
imsimta restart dispatcher コマンドを実行して SMTP サーバを再起動します。
メッセージファイルの取り込み処理を開始するには、エンドユーザにメッセージ部分を含むメッセージを再送信してもらいます。
メッセージがチャネルに入るときに、メッセージが imsimta qm stop コマンドによって停止されていると、メッセージはチャネル内で停止します。詳細は、ステップ 手順 3 を参照してください。
メッセージのパスにある次のチャネルを手動で起動する前に、メッセージファイルをコピーして名前を変更します。以下の UNIX プラットフォームの例を見てください。
チャネルでメッセージの処理を再開し、メッセージのパスにある次の宛先チャネルのキューに入れます。これを行うには、imsimta qm start コマンドを使用します。
メッセージが処理される順番を識別するために、メッセージをトラップしてコピーするたびに、メッセージの拡張子に番号を付けることをお勧めします。
- # cp ZZ01K7LXW76T7O9TD0TB.00 ZZ01K7LXW76T7O9TD0TB.KEEP1
- 通常、メッセージファイルは、/server-root/msg-instance/imta/queue/destination_channel/001 のようなディレクトリにあります。destination_channel は、メッセージが通過する次のチャネル (tcp_intranet など) です。destination_channellディレクトリにサブディレクトリ (001、002 など) を作成する場合は、チャネルに subdirs キーワードを追加します。
/server-root/msg-instance/log/imta/ ディレクトリにある対応するチャネルログファイル (たとえば、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 を保存します。
ディレクトリ /server-root/msg-instance/imta/config の imta.cnf ファイルにある該当するチャネルから、slave_debug キーワードと master_debug キーワードを削除します。
mm_debug=0 をリセットし、ディレクトリ /server-root/msg-instance/imta/config の option.dat ファイルにある log_message_id=1 を削除します。
imsimta cnbuild を使用して設定を再コンパイルします。
imsimta restart dispatcher コマンドを実行して SMTP サーバを再起動します。
チャネルプログラムの起動と停止が終わるまでには、トラブルシューティングのために使用できる以下のファイルがあるはずです。
各チャネルプログラムのメッセージファイルのすべてのコピー (たとえば、ZZ01K7LXW76T7O9TD0TB.KEEP1)
各宛先チャネルの channel_master.log-* ファイルのセット
メッセージのパスを示す mail.log_current レコードのセット
tcp_local_slave.log-* ファイルを調べて、メッセージがキューに入れられたときにメッセージにメッセージ部分があったかどうかを確認します。
- どのファイルにも、mail.log_current レコードにあるメッセージ ID: ヘッダー行に一致するタイムスタンプとメッセージ ID がある必要があります。メッセージが受取人にバウンスされた場合は例外です。バウンスされたメッセージには元のメッセージとは異なるメッセージ ID 値が付いています。
メッセージファイルを詳しく調べて、メッセージ部分が変更されたり欠落した場所を確認します。
- 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 に移動する必要があります。iPlanet Messaging Server の MTA の場合は、トラブルシューティング処理すべてを繰り返す必要があります (「メッセージパスにあるチャネルを識別する」、「データを収集するためにチャネルを手動で起動および停止する」、およびこの節を参照)。その他の MTA が自分の管理下にない場合は、問題を報告したユーザが特定のサイトに問い合わせる必要があります。
一般的な MTA の問題と解決策
この節では、MTA の設定と操作で一般的に起こりやすい問題と解決策を示します。
「設定ファイルまたは MTA データベースに対する変更が有効にならない」
設定ファイルまたは MTA データベースに対する変更が有効にならない
設定、マッピング、変換、セキュリティ、オプション、またはエイリアスファイルに対する変更が有効になっていない場合は、以下のステップを実行したかどうかをチェックします。
MTA が、メールを送信するが受信しない
ほとんどの MTA チャネルは、スレーブまたはチャネルプログラムに依存して、受信メッセージを受信します。MTA がサポートしているいくつかの転送プロトコル (TCP/IP や UUCP など) の場合、転送プロトコルが標準サーバではなく MTA スレーブプログラムをアクティブにしていることを確認する必要があります。ネイティブの sendmail SMTP サーバから MTA の SMTP サーバへの置換は、iPlanet Messaging Server のインストールの際に実行されます。詳細は、『iPlanet Messaging Server UNIX 用インストールガイド』を参照してください。マルチスレッド SMTP サーバの場合、SMTP サーバの起動はディスパッチャによって制御されます。ディスパッチャが SMTP サービスより大きいか等しい MIN_PROCS 値を使用して構成されている場合は、少なくとも 1 つの SMTP サーバプロセスが常に実行している必要があります (SMTP サービスの MAX_PROCS 値によっては複数の場合もあります)。imsimta process コマンドを使用して、SMTP サーバプロセスがあるかどうかをチェックすることもできます。詳細については、『iPlanet Messaging Server リファレンスマニュアル』の MTA コマンドラインユーティリティの章を参照してください。
受信 SMTP 接続時のタイムアウト
受信 SMTP 接続時のタイムアウトは、システムリソースやその割り当てに関連していることがよくあります。以下の方法を使用して、受信 SMTP 接続時のタイムアウトの原因を識別することができます。
同時に許可する受信 SMTP 接続の数をチェックします。これは SMTP サービスのディスパッチャ設定である MAX_PROCS および MAX_CONNS によって制御され、許可できる同時接続数は MAX_PROCS*MAX_CONNS です。接続数が少なすぎる場合、システムリソースに余裕があれば、この数を増やすことを考慮してください。
システムが過負荷になっていて拡張されすぎている場合は、タイムアウトを完全に回避するのは難しくなります。使用できるもう 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 (iPlanet Messaging Server 5.1 (built May 7 2001))
220 個の見出しの応答が遅い場合や、SMTP サーバで pstack コマンドを実行すると以下の iii_res* 関数 (名前解決検索が実行されていることを示す) が表示される場合があります。
- 接続して 220 個の見出しを受信しても、その他のコマンド (ehlo や mail from など) が応答を許可していない場合は、imsimta test -rewrite を実行して設定が正しいことを確認する必要があります。imsimta dirsync コマンドを使用している場合は、最近このコマンドを実行したことを確認します。dirsync が失敗した場合は、SMTP サーバ内のコマンドが応答を受信しないこともあります。このような場合、imsimta dirsync -F を実行すると問題を解決できます。ただし、dirsync ロックファイルが最初に削除されている必要があります。
febe2c04 iii_res_send (fb7f4564, 28, fb7f4de0, 400, fb7f458c, fb7f4564) + 142c
febdfdcc iii_res_query (0, fb7f4564, c, fb7f4de0, 400, 7f) + 254
受信 SMTP over TCP/IP メールを処理しているチャネル (通常は、tcp_local と tcp_intranet) 上に slave_debug キーワードを設定することもできます。これを実行したあと、最新の tcp_local_slave.log-uniqueid ファイルを見直して、タイムアウトになったメッセージの特性を識別します。たとえば、受取人の数が多すぎる受信メッセージがタイムアウトになった場合は、チャネル上で expandlimit キーワードを使用することを考慮してください。
- このような場合は、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 サーバでメッセージを処理する必要があります。
メッセージがキューから取り出されない
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
NSLOOKUP ユーティリティを使用して、MX レコードがこのホストに存在していることを確認します。MX レコードが存在していない場合、直接ホストへの接続を試みる必要があります。MX レコードが存在している場合、指定された MX リレーに接続する必要があります。MTA は MX 情報を優先して処理します (優先して処理しないように設定されている場合は除く)。「TCP/IP MX レコードのサポート」も参照してください。
DNS を使用しない TCP/IP ネットワーク上で iPlanet Messaging Server が稼働している場合は、ステップ (手順 1) と (手順 2) をスキップすることができます。代わりに、TELNET を使用して、問題となっているホストに直接アクセスすることができます。MTA が使用するホスト名と同じホスト名を使用する際は、注意してください。ホスト名を確認するには、MTA の最後の試行に関連するログファイルを確認します。ホストファイルを使用している場合は、ホスト名情報が正しいことを確認する必要があります。ホスト名ではなく DNS を使用することを、強くお勧めします。この例では、DNS (ドメインネームサービス) は xtel.co.uk の指定された MX リレーの名前を返しています。これは MTA の実際の接続先になるホストです。複数の MX リレーがリストにある場合、MTA は各 MX レコードを、優先度がもっとも低いものから順に、連続して試行します。
リモートホストへの接続がある場合は、SMTP サーバのポート 25 への TELNET を使用して、受信 SMTP 接続を受け入れているかどうかチェックする必要があります。
注 ポートを指定しないで TELNET を使用すると、リモートホストが通常の TELNET 接続を受け入れることがわかります。これは、SMTP 接続を受け入れることを示すわけではありません。多くのシステムは、正規の TELNET 接続は受け入れても SMTP 接続は拒否します。または、その逆になります。そのため、常に SMTP ポートのテストを行う必要があります。
- 前述の例では、リモートホストは SMTP ポートへの接続を拒否しています。これが、MTA がメッセージの配信に失敗した理由です。この接続は、リモートホストの設定ミスやリモートホスト上での何らかのリソース不足のために拒否されることがあります。このような場合は、ローカルで問題解決を行うことはできません。通常は、MTA にメッセージの再試行を続けさせることになります。
TCP/IP ホストへの接続をテストする場合、インタラクティブテストを使用して問題が発生しないのであれば、ほぼ確実に、問題は MTA が最後にメッセージを配信しようとしたあとに解決されています。該当するチャネルで imsimta submit tcp_channel を再度実行して、メッセージがキューから取り出されているかどうかを確認することができます。
MTA メッセージが配信されない
メッセージ転送に関する問題のほかに、2 つの一般的な問題があります。この問題はメッセージキューにある未処理のメッセージに起因することがあります。
キューキャッシュはキューディレクトリにあるメッセージと同期しません。MTA キューサブディレクトリにある配信待ちのメッセージファイルは、インメモリキューキャッシュに入れられます。起動時にチャネルプログラムは、このキューキャッシュを調べて、キューにあるどのメッセージを配信するかを確認します。メッセージファイルがキューの中にあっても、対応するキューキャッシュエントリがない場合もあります。
特定のファイルがキューキャッシュにあるかどうかをチェックするには、imsimta cache -view ユーティリティを使用します。ファイルがキューキャッシュにない場合は、キューキャッシュを同期させる必要があります。
処理するログファイルを作成できないために、チャネル処理プログラムの実行は失敗します。アクセス権、ディスク容量、および制限容量をチェックします。
キューキャッシュを同期させてもメッセージがまだ配信されない場合は、ジョブコントローラを再起動する必要があります。これを行うには、imsimta restart job_controller コマンドを使用します。
- キューキャッシュは、通常は 4 時間ごとに同期されます。必要に応じて、imsimta cache -sync を使用してキャッシュを手動で再同期することができます。同期が終わると、チャネルプログラムは、新しいメッセージが処理されたあとで、元の未処理メッセージを処理します。デフォルト (4 時間) を変更する場合は、sync_time=timeperiod を追加することで、ディレクトリ /server-root/msg-instance/imta/config にある job_controller.cnf ファイルを変更する必要があります。ここで、timeperiod は、キューキャッシュを同期させる頻度です。timeperiod は 30 分より長くする必要があります。以下の例では、job_controller.cnf のデフォルトのグローバルセクションに 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 submit channel を実行して、imsimta cache -sync を実行したあとにメッセージのバックログを空にすることができます。メッセージのバックログが大きい (1000 以上) 場合、チャネルを空にするのに時間がかかることがあるので、注意してください。
- キューキャッシュの情報の概要については、imsimta qm -maint dir -database -total を実行してください。
メッセージがループしている
メッセージがループしていることを MTA が検出すると、そのメッセージは HELD ファイルとして保持されます。「.HELD メッセージを診断して整理する」を参照してください。場合によっては、MTA がメッセージループを検出できないときもあります。最初のステップは、メッセージがループしている理由を確認することです。問題のメッセージのコピー (MTA キュー領域にあるとき)、問題のメッセージに関連する MTA メールログエントリ (該当チャネルの MTA 設定ファイルで logging チャネルキーワードが有効になっている場合)、および該当チャネルの MTA チャネルのデバッグログファイルを確認します。問題のメッセージの From: および To: アドレス、Received: ヘッダー行、およびメッセージ構造 (メッセージ内容のカプセル化の種類) を確認して、発生したメッセージループの種類を特定することができます。
ポストマスターアドレスが壊れている。
Received: ヘッダー行を削除すると、MTA はメッセージのループを検出できなくなります。
- MTA では、電子メールを受信するために、ポストマスターアドレスが正しく機能しなければなりません。ポストマスターへのメッセージがループしている場合は、メッセージを受信できるアカウントをポイントする適切なポストマスターアドレスが設定されているかどうかチェックします。
ほかのメッセージングシステムによる通知メッセージの処理が正しくなく、通知メッセージに応答して再度カプセル化されたメッセージが生成されている。
- 通常のメッセージループの検出は、Received: ヘッダー行に基づいています。Received: ヘッダー行が MTA システム自体で明示的に、あるいはファイアウォールのような別のシステム上で削除されている場合、メッセージループを適切に検出できなくなることがあります。このような場合は、Received: ヘッダー行が知らないうちに削除されていないかどうかチェックします。また、メッセージがループしている根本的な原因もチェックします。考えられる原因は、システム名の割り当ての問題 (システムが自分の名前の変形を認識しないように設定されている場合)、DNS の問題、該当するシステムに承認可能なアドレス情報がないこと、あるいはユーザアドレス転送エラーなどです。
- インターネット規格では、通知メッセージ (メッセージ配信やメッセージ差し戻しのレポート) にメッセージループを防ぐための空のエンベロープ From: アドレスがあることを必要としています。ただし、メッセージングシステムによってはこのような通知メッセージを正しく処理しない場合もあります。このようなメッセージングシステムは、通知メッセージを転送または返送するときに、新しいエンベロープ From: アドレスを挿入することがあります。これがメッセージループの原因になることもあります。解決策は、通知メッセージを正しく処理していないメッセージングシステムを修復することです。
.HELD メッセージを診断して整理する
メッセージがサーバまたはチャネル間で返送されていることを MTA が検出すると、配信は停止され、メッセージは /server-root/msg-instance/imta/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 はメッセージを無視し、それ以上配信は試行されません。このような問題が発生したときは、メッセージ内のヘッダー行を見て、サーバまたはチャネルがメッセージをバウンスしているかどうか確認します。必要であればエントリを修正してください。
以下の手順に従って .HELD メッセージを再試行することもできます。
拡張子 .HELD を 00 以外の任意の 2 桁の数字 (たとえば、06) に変更します。
これらのステップは何回か実行することが必要かもしれません。これは、Received: ヘッダー行が蓄積され、それによってメッセージに再度 .HELD とマークが付けられている可能性があるためです。
注
受信したメッセージがエンコードされている
MTA が送信したメッセージは、エンコードされた形式で受信されます。たとえば、以下のようになります。これらのメッセージは、MTA デコーダコマンド imsimta decode を使用すれば、デコードされて表示されます。詳細は、『iPlanet Messaging Server リファレンスマニュアル』を参照してください。
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) と言われることがよくあります。ディレクトリ同期コマンド (imsimta dirsync) は、ユーザのフィルタに関する情報を含む MTA の SSR データベースを更新します。SSR データベースは短いフィルタ (1016 バイト未満) を保存し、LDAP DN は長いフィルタ用に使われます。MTA は、imsimta dirsync コマンドでディレクトリサーバが更新されるまではユーザのフィルタに対する変更を認識しません。SSR の詳細は、「第 2 部 メールボックスフィルタ」を参照してください。
「SSR 規則をテストする」
以下のコマンドを使用して、MTA のユーザフィルタをチェックします。
# imsimta test -rewrite -debug -filter user@domain さらに、slave_debug キーワードを tcp_local チャネルに追加して、フィルタが適用される状態を確認することができます。この結果は tcp_local_slave.log ファイルに表示されます。十分なデバッグ情報を得るためには、ディレクトリ /server-root/msg-instance/imta/config にある option.dat ファイルに mm_debug=5 を追加します。
トラブルシューティングの手順
SSR の問題を診断する前は、必ず以下の手順を確認しておいてください。
imsimta dirsync コマンドを使用している場合は、ims-ms チャネルに、以下のフィルタ
ssrd:$a
および
fileinto $u+$s@$d が、ディレクトリ /server-root/msg-instance/imta/config の imta.cnf ファイル内でマークされていることを確認します。imsimta dirsync コマンドを使用している場合は、imsimta dirsync コマンドがフィルタ情報を適切に同期することを確認します。これを行うには、ディレクトリ /server-root/msg-instance/ から以下のコマンドを実行します。このコマンドは必ずメッセージングサーバのユーザとして実行してください。
# configutil -l -o service.imta.ssrenabled -v true
OK SET
# configutil | fgrep ssr
local.imta.ssrenabled = yes
service.imta.ssrenabled = true
フィルタにシンタックスの問題がある場合は、tcp_local_slave.log-* ファイルで以下のメッセージを探します。
Error parsing filter expression:...
一般的なエラーメッセージ
MTA が起動に失敗すると、コマンドラインに一般的なエラーメッセージが表示されます。この節では、共通の一般的なエラーメッセージの説明と診断を示します。
注 MTA 設定を診断するには、imsimta test -rewrite -debug ユーティリティを使用して MTA のアドレス書き換えとチャネルマッピング処理を調べます。このユーティリティを使用すれば、メッセージを実際に送信しなくても設定をチェックすることができます。「MTA 設定をチェックする」を参照してください。
MTA サブコンポーネントは、この章では説明していないほかのエラーメッセージを発行することもあります。各サブコンポーネントの詳細は、『iPlanet Messaging Server リファレンスマニュアル』の MTA コマンドラインユーティリティの章と、第 6 章から第 10 章を参照してください。ここでは、以下のタイプのエラーについて説明します。
「mm_init でのエラー」
mm_init でのエラー
mm_init でのエラーは、通常は MTA の設定の問題を示します。imsimta test -rewrite ユーティリティを実行する場合は、これらのエラーが表示されます。imsimta cnbuild などのその他のユーティリティ、チャネル、サーバ、またはサーバがこのようなエラーを返すこともあります。よく発生する mm_init エラーには以下のものがあります。
「エイリアスが同じではありません」
「ch_ 機能の初期化中のエラー : コンパイルした文字セットのバージョンが一致しません」
「ch_ 機能の初期化中のエラー : 空き容量がありません」
エイリアスが同じではありません
エイリアスファイルのエントリの右側が適切にフォーマットされていません。
エイリアスインクルードファイルを開くことができません
エイリアスファイルに含まれているファイルを開くことができません。
重複するエイリアスが見つかりました
エイリアスファイルの 2 つのエントリが両方とも左側にあります。重複するものを見つけて削除する必要があります。error line #XXX というエラーメッセージを探します。XXX は行番号です。この行にある重複のエイリアスを修正することができます。
チャネルテーブル内でホストが重複しています
このエラーメッセージは、MTA の設定に 2 つのチャネル定義があり、両方に同じ正規ホスト名があることを示しています。MTA 設定ファイル (imta.cnf) の書き換え規則 (上部) に関係のない空白行があると、MTA は設定ファイルの残りの部分をチャネル定義と解釈します。ファイルの最初の行が空白でないことを確認してください。同じパターンを持つ書き換え規則 (左側) が複数あると、MTA はそれらの書き換え規則を、一意でない正規のホスト名を含むチャネル定義と解釈します。正規のホスト名が重複しているチャネル定義がないかどうか、また、ファイル上部 (書き換え規則の部分) に不適切な空白行がないかどうか、MTA の設定をチェックしてください。
重複するマッピング名が見つかりました
このメッセージは、2 つのマッピングテーブルに同じ名前が付いていて、これらの重複するマッピングテーブルのいずれかを削除する必要があることを示します。ただし、マッピングファイル内のフォーマットエラーによって、MTA が何かを間違ってマッピングテーブル名と解釈することもあります。たとえば、マッピングテーブルエントリが適切にインデントされていないと、MTA はエントリの左側が実際にマッピングテーブル名であるとみなします。マッピングファイルが一般の形式であることと、マッピングテーブル名をチェックしてください。
注 空白行はマッピングテーブル名を含む行の前と後ろに付ける必要があります。ただし、空白行をマッピングテーブルのエントリ間に入れないでください。
マッピング名が長すぎます
このエラーは、マッピングテーブル名が長すぎるので、短くする必要があることを示しています。マッピングファイル内のフォーマットエラーによって、MTA が何かを間違ってマッピングテーブル名と解釈することもあります。たとえば、マッピングテーブルエントリが適切にインデントされていないと、MTA はエントリの左側が実際にマッピングテーブル名であるとみなします。マッピングファイルとマッピングファイル名をチェックしてください。
ch_ 機能の初期化中のエラー : コンパイルした文字セットのバージョンが一致しません
このメッセージが表示された場合は、imsimta chbuild コマンドを使用して、コンパイル済みの文字セットテーブルを再コンパイルして再インストールする必要があります。詳細は、『iPlanet Messaging Server リファレンスマニュアル』を参照してください。
ch_ 機能の初期化中のエラー : 空き容量がありません
通常、このエラーメッセージは、MTA 文字セットの内部テーブルのサイズを変更し、以下のコマンドでコンパイル済み文字セットテーブルを再構築する必要があることを意味しています。imsimta chbuild -noimage -maximum -option
imsimta chbuildこの変更を加える前に、ほかには何も再コンパイルまたは再起動する必要がないことを確認してください。imsimta chbuild の詳細は、『iPlanet Messaging Server リファレンスマニュアル』の MTA コマンドラインユーティリティの章を参照してください。
システムのローカルホストエイリアスまたは固有名詞が長すぎます
このエラーは、ローカルホストエイリアスまたは固有名詞が長すぎることを示します (オプションで、チャネルブロックの 2 番目以降の名前の右側にある)。ただし、MTA 設定ファイル内でこのエラーより前にシンタックスエラー (書き換え規則に関係のない空白行がある場合など) がある場合は、MTA が何かを間違ってチャネル定義と解釈することもあります。設定ファイルの指定されている行をチェックするだけでなく、その行より上にほかのシンタックスエラーがないかどうかもチェックしてください。特に、このエラーが発生した行が書き換え規則を意図する行である場合は、その行より上に関係のない空白行がないかどうかを必ずチェックしてください。
同じエイリアスアドレスがありません
エイリアスファイル内のエントリの右側 (変換値) がありません。
チャネルの正規のホスト名がありません
このエラーは、チャネル定義ブロックに必須の 2 番目の行 (正規のホスト名の行) がないことを示しています。チャネル定義ブロックの詳細は、『iPlanet Messaging Server リファレンスマニュアル』の MTA の設定およびコマンドラインユーティリティの章と、第 8 章「チャネル定義を設定する」を参照してください。それぞれのチャネル定義ブロックの前と後ろには空白行が必要ですが、空白行をチャネル定義のチャネル名と正規のホスト名の行の間に入れることはできません。また、空白行は MTA 設定ファイルの書き換え規則部分には入れることはできません。
正規のホスト名が長すぎます
チャネルの正規のホスト名 (チャネル定義ブロックの 2 行目) は、長さが 40 オクテットに制限されています。チャネル上で長めの正規ホスト名を使用しようとしている場合は、それをプレースホルダ名まで短くしてから、書き換え規則を使用してその長めの名前がその短い正規ホスト名に一致するようにします。このような状況は、l (ローカル) チャネルホスト名を使用しているときに起こることがあります。たとえば、以下のようになります。
l subdirs 20 viaaliasrequired maxjobs 7 pool LOCAL_POOL newt Create Rewrite Rule: newt.salamander.lizard.gecko.komododragon.com $U%$D@newt l (ローカル) チャネルを使用しているときは、REVERSE マッピングテーブルを使用する必要があります。使用法とシンタックスの詳細は、『iPlanet Messaging Server リファレンスマニュアル』の 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
このエラーはジョブコントローラのログファイルで見られることがあります。その他のスワップ空間のエラーは設定によって異なります。
以下のコマンドを使用して、スワップ空間の空き容量と使用容量を確認します。
Solaris システム : swap -s (MTA プロセスがビジー状態のとき)、ps -elf、または tail /var/adm/messages
HP-UX システム : swapinfo または tail /var/adm/syslog/syslog.log
Windows NT システム : より多くの空間が必要な場合や、ほかの場所により高速のドライブがある場合は、デフォルトのハードドライブ (C:¥ など) 以外のドライブ上にページングファイルサイズを設定することができます。利用可能な容量をチェックしたり、新しいページングファイルサイズを設定するには、以下の手順に従います。
ファイルのオープンまたは作成エラー
メッセージを送信するために、MTA は設定ファイルを読み取って、MTA メッセージキューディレクトリにメッセージファイルを作成します。設定ファイルは、MTA または MTA の SDK に対して書かれたプログラムが読み取ることのできるものでなければなりません。適切な権限はこれらのファイルのインストール中に割り当てられます。設定ファイルを作成する MTA ユーティリティとプロシージャも、権限を割り当てます。ファイルがシステムマネージャ、特権を持つほかのユーザ、またはサイト固有のプロシージャによって保護されている場合、MTA は設定情報を読み取ることができない場合があります。その結果、「ファイルオープン」エラーや予測不能な動作が発生します。設定ファイルの読み取りに関する問題が発生したときは、imsimta test -rewrite ユーティリティが追加情報をレポートします。『iPlanet Messaging Server リファレンスマニュアル』の MTA の章にある imsimta test -rewrite の説明を参照してください。MTA が、権限を持つアカウントから機能していて、権限のないアカウントからは機能していないように見える場合は、MTA テーブルディレクトリのファイルアクセス権が問題の原因と思われます。設定ファイルとそのディレクトリのアクセス権をチェックしてください。「危険なファイルの所有権をチェックする」を参照してください。
「ファイル作成」エラーは、通常、MTA メッセージキューディレクトリにメッセージファイルを作成する際に問題が発生したことを示しています。ファイル作成に関する問題の診断については、「メッセージキューディレクトリをチェックする」を参照してください。
不正なホスト/ドメインエラー
このエラーは、ブラウザで MTA にアドレスを指定したときに見られることがあります。また、このエラーは、据え置かれて、エラー返送メールメッセージの一部として返送されることがあります。どちらの場合もこのエラーメッセージは、MTA が指定したホストにメールを配信できないことを示しています。メールが指定したホストに送信されていない原因を確認するには、以下のトラブルシューティング手順に従います。
該当するアドレスにスペルミスがないかどうか、コピーミスがないかどうか、存在していないホストまたはドメインの名前を使用していないかどうかを確認します。
imsimta test -rewrite ユーティリティを使って該当するアドレスを実行します。このユーティリティを使用してもアドレスで「不正なホスト/ドメイン」エラーが返される場合は、MTA の imta.cnf ファイルと関連ファイルにアドレスを処理する規則がありません。MTA が正しく設定されているかどうか、設定の際のすべての質問に適切に回答したかどうか、設定情報が最新のものになっているかどうかを確認してください。
imsimta test -rewrite によってアドレスでエラーが発生しない場合、MTA はアドレスの処理方法を決定できますが、ネットワーク転送はそれを受け入れません。追加の詳細については、配信試行の際に作成された該当するログファイルを調べることができます。一時的なネットワークのルーティングエラーまたはネームサービスエラーが発生したことにより、エラーメッセージが返されることはありません。ただし、ドメインネームサーバの設定が大幅に間違っていると、このようなエラーが発生する可能性があります。
インターネット上の場合は、MX レコード検索をサポートするように TCP/IP チャネルが正しく設定されているかどうかチェックします。多くのドメインアドレスはインターネットに直接アクセスすることはできず、メールシステムが正しく MX エントリを解決する必要があります。インターネット上の場合、および TCP/IP が MX レコードをサポートするように設定されている場合は、MX サポートを有効にするように MTA を設定する必要があります。詳細は、「TCP/IP 接続と DNS 検索のサポート」を参照してください。TCP/IP パッケージが MX レコード検索をサポートするように設定されていない場合は、MX 専用ドメインにアクセスすることはできません。
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 パケットトレース) を実行して、何を送信または受信したかを確認することもできます。
前へ 目次 索引 DocHome 次へ
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.
最新更新日 2002 年 2 月 27 日