補足授業4. メールは何処にいたのか

過去のブログを掘り起こして、当時分からずじまいだったことをAIニキの力を借りて解決していくシリーズの5回目です。

第5回目は、2012年9月3日の内容です。懐かしいね。

メールは何処にいたのか


稲川淳二風に書いたつもりらしい。流行ってたんか。

当時の話をざっくりまとめると、自分のサーバーにメール送信のテストをしたら一向に届かずで、maillogにも残ってないが、telnetで確認したら接続はできてるとか。

犯人はiptablesだった。で、検証のために設定したルールをなおし忘れていて、送信元のIPアドレスをdropしてたのだった。iptablesをなおして就寝。

朝起きたらメールが届いていた。メールヘッダーのReceivedを見たら、サーバー間で到着した時間が40分ほど離れていた。

40分だよ!?

どこに居たんでしょう、という話だった。

発想がユニーク!知らないというのはたまにこんな考えもしないような考え方をしていていいね。


コメント欄でほげさんにすでに指摘してもらっていて「再送され続けてただけじゃないですか」ってことですでに答えは出てるのだけど

SMTPというのはメールを送受信するためのプロトコルで、メールが届かなかった場合に一定時間後に再送する仕組みが組み込まれている。これをリトライとかキューイングとかいう。

TCPの話は、iptablesで弾かれてたとしたら、サーバーからのSYNの応答もなくてそもそも接続も確立できてなかったわけだや。SMTPは設定に従って再送を続ける。iptablesをなおした瞬間に通り道が開いて、キューに積まれていたメールが届いた、という感じだ。

てことでメールは何処へ。というかずっと手元にあったんだ。

すっきりしたな。


iptablesのDROPとREJECTの違い


少し補足しておくと。

iptablesでパケットを弾く方法にはDROPとREJECTがある。

REJECTは「拒否したよ」というエラーを送信元に返すので、送信元はすぐに失敗を知ることができる。一方DROPは何も返さずに黙って捨てる。

送信元からすると、DROPの場合は「届いたのか届いてないのかわからない」という状態になるので、タイムアウトするまでひたすら待つことになる。

Related Posts


投稿者: Takeken

インターネット利用者のITリテラシーを向上したいという設定の2次元キャラです。 サーバー弄りからプログラミングまで手を付けた自称エッセイストなたけけんの物語。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です