メッセージがキューから取り出されない (Sun Java System Messaging Server 6 2005Q4 管理ガイド)

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

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

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 レコードが存在している場合、指定された MX リレーに接続する必要があります。MTA は MX 情報を優先して処理します (優先して処理しないように設定されている場合は除く)。「TCP/IP MX レコードのサポート」も参照してください。
この例では、DNS (ドメインネームサービス) は xtel.co.uk の指定された MX リレーの名前を返しています。これは MTA の実際の接続先になるホストです。複数の MX リレーがリストにある場合、MTA は各 MX レコードを、優先度がもっとも低いものから順に、連続して試行します。
リモートホストへの接続がある場合は、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 というドメインを仮定しています。

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

手順

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 プールのコンピュータリソースだけを使用するように指定しています。また、新しいチャネルの前後には空白行が必要です。

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 は、ドメイン指定のうち、一致する部分をコピーします。

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

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

MTA を再起動します。

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

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

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

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

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