2006年7月14日

[linux-users:106756] Re: qmail-remoteが詰まる

則松です。

鈴木様、ご指摘ありがとうございます。

すみません。私の矛盾の記述がちょっとおかしかったようです。
確かにMXレコードが登録されているのと、接続先サーバの
死活は別問題でしたね。


私が矛盾している、と感じていたのは、

> ps axの表示を見ていた限り、ですが、恐らく60秒よりも長い時間、
> qmail-remoteプロセスが立ち上がっていたように思えます。
> ですので、今回の話に限ると、恐らくSMTP接続そのものはできていたの
> ではないかと考えています。

qmail-remoteが詰まって見えたのが、timeoutremoteのタイムアウト秒数設定
によっていた、という仮定の場合ですと、MXは引けて、その先のサーバも
存在し、コネクションは受け入れたが、その後のSMTPコマンドを受け付け
なかった、ということなのではと考えていたのですが、

> Jul 13 12:19:16 sv qmail: 1152483556.998978 starting delivery 84730: msg 883038 to remote tyuuichiwq@xxxxx
> Jul 13 12:19:37 sv qmail: 1152483577.039173 delivery 84730: deferral: Sorry,_I_couldn't_find_any_host_by_that_name._(#4.1.2)/

であれば、先方サーバが反応しないことが分かった時点でqmail-remoteは停止
するはずで、この場合先方サーバは活きていない。
その場合、qmail-remoteの停止はもっと短い時間で行われるのかな、と。
で、そこが矛盾しているなぁ、と思っていました。

それで、私としてはご指摘いただいた

> しかし、DNSで引けるからと言っても、それはDNSに登録だけされているだけで
> 実際には相手のサーバが死んでいるとか、存在しない可能性もあるので
> 実際には相手サーバが死んでいるか、存在せず qmail が接続できなかったために
> ログには[ Sorry,_I_couldn't_find_any_host_by_that_name. ] と記録されたという可能性はありませんか?

ではなく、先方サーバは活きてはいるが反応がおかしい、という
ように考えていたのです。

この考えに何か問題があるのかもしれません・・・
ということで、ご指摘いただいたtelnet接続をやってみました。

まずは、実験的にローカルに対して。
$ telnet localhost 25
Trying 127.0.0.1...
Connected to localhost (127.0.0.1).
Escape character is '^]'.
220 xxx.example.jp ESMTP

となり、SMTPコマンドを受けつけてくれました。(当然ですね)

で、問題の先方サーバに。
$ telnet mx.example.com 25
Trying xxx.xxx.xxx.xxx(接続先IP)...

telnet: connect to address xxx.xxx.xxx.xxx: Connection timed out

ということで、3分ほど待ってtelnetがタイムアウトしました。

この場合ですと、先方サーバは死んでいるが、サーバ間のどこかの
ネットワークの問題か何かで、コネクションが張れない、という
ことになるのかな?

なんだか混乱してきてしまいました・・・

> 他にも CatchALL アカウントを作成して宛先不明のメールを全部特定アカウントで
> 受信してしまうという手段もありますが、メールサーバの管理者の方が大変なことになりそうですね(笑。
なるほど。確かにこの手段もありますね。
ありますが・・・・(苦笑


投稿者 xml-rpc : 2006年7月14日 16:42
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/39560
トラックバック
コメント
コメントする




画像の中に見える文字を入力してください。