自宅で使っているプロバイダが、突然OP25Bを導入したことは昨日話したとおりですが、昨日その対応を自社のメールサーバーに行ってみた。

元々、SMTP_AUTHをすっと前から導入していたので、 OP25Bが導入されてもポート５８７番でリッスンできるようにするだけなので、作業は簡単です。

実際、postfixの設定を変更して、自社ファイアウォールの当該ポートを開けて、試しに外部のメールに向けてテストメールを送信しました。　ポート５８７番を使っても難なく送信できます。

さて、作業は終わり...。　　　と思っていました。

が、実は終わっていなかったのです。

しばらく経って気が付いたのですが、外部のメールアカウント（プロバイダから発行されているメール）には、一向にメールが届きません。　最近、遅延が起きていたので、その要因もあるのかな？　と思っていましたが、それにしても遅すぎます。

そこで、SMTPサーバーのログ(/var/log/mail.log)を見てみました。 　そうすると...

Nov  1 15:14:18 localhost postfix/smtp[3115]: connect to smtp.xxx.or.jp[220.11.22.33]: Connection timed out (port 25)
Nov  1 15:14:18 localhost postfix/smtp[3115]: D1F2526F1E: to=< このメールアドレスはスパムボットから保護されています。観覧するにはJavaScriptを有効にして下さい >, relay=none, delay=30, status=deferred (connect to smtp.xxx.or.jp[220.11.22.33]: Connection timed out)

などとメッセージが出ているではないですか。
メーラーからみると、すんなり送信完了となっていたので、気づくのが遅れましたが、SMTPサーバーの方で相手からのACKがないために、配送待ちになっていたようなのです。

「おかしい。　理論上はポート５８７番は２５番の代理なだけで、SMTPサーバーは同じ動きをするはずだが..。」

「プロバイダのSMTPサーバが、５８７番を使ったときだけ、応答が返さない仕様なのか？」

「いやいや、それでは、世の中のメールが全部届かなくなってしまう...。」

「そうすると、こちらの戻りポートに何か問題があるのか？」

と、不思議が不思議を呼びます。

なんだか原因がつかめないので、パケットアナライザーでもかけようかと思ったとき、ふと「ファイアウォールで開けたのは、もしかすると一方通行のみ？」という疑問がわきました。

調べてみると、その通りです。　
なんか、理由が分かってしまうとガッカリです。

システムの開発でもそうですが、自分が設定した思い込みのせいで、原因究明が遅れることがしばしば起きます。　「自分では確かに○○したはず」という思い込みが、その部分を疑わなくなる一因なんですね。

常々、「まず自分を疑う」ことを肝に命じていますが、現実はなかなか出来ないものですね。

もっと精進しないと..。