« メガてりやきは食べない | メイン | 6月12日 来週は試験 »
2007年06月12日
エラーメールにご用心
あるアドレスに送信すると、複数のあて先に転送するような設定をしていたのですが、転送先のクオータが超え、エラーメールがループしてしまいました…。
ループしたエラーメールが届いた Gmail の容量。
エラーメールを削除した後の Gmail の容量。実に 1.5GB ものエラーメールが届いていました。途中の経路で遮断しているので、遮断していない転送先には、もっと多くのメールが届いていた可能性があります…。
行った対処について。
.procmail を利用して転送していたので、エラーメールの送信元になる MAILER-DAEMON のメールは、全て削除するようにしました。これで、新たにエラーメールが他の転送先に転送されるのを防ぎました。
$ vi /etc/postfix/main.cf ... bounce_queue_lifetime = 1h maximal_queue_lifetime = 1h
一時的に再送期限を短縮しました。通常は、宛先（転送先）にエラーが発生すると、数日間（デフォルトは5日間）、再送信を試みるのですが、その再送期限を1時間に設定しました。出来れば、再送そのものを停止したかったのですが、どうも 0h にすると無効（デフォルト）になるという噂を耳にしたので。検証はしていません。
再送期間を短縮することにより、クオータの問題が解決した後に、エラーメールが届き始めるのを防ぎました。
エラーメール怖い。
2007年06月12日 02:37 | Technology
トラックバック
コメント
大学でも時々やる人がいます。そのたびにセンターのメールハブ（ウィルスチェッカー）にとてつもない負荷がかかって大学全体のメール遅延が起きます。
そういうループは、計ったように全員procmail使ってます。エラーメールは転送しないことをテストしないといけません。
しかし、なんでデフォルトでループ起こす設定になってるんだか。こんな腐ったソフト禁止したい。
投稿者 M : 2007年06月12日 09:37
>> M さん
多くのユーザを抱えている環境だと、なお大変ですね…。
.forward は、安全策として数回ループすると自動的に停止するのですが…。procmail は、そういう安全策が無いようなので困り者。
エントリに書いた対応では、完全にループを防ぐことが出来ません。ループを事前に防ぐレシピを別エントリに書くことにします。
投稿者 ceekz : 2007年06月12日 10:28
> .forward は、安全策として数回ループすると自動的に停止するのですが…。
静的にループを作ってしまったときはそうなりますが、バウンスしてくるエラーメールについては「数回ループすると自動的に停止」というのは無理なんじゃないかと思います。
Received: 行の数や Delivered-To: ヘッダ、X-Loop: ヘッダなどでループをチェックするのは、バウンスによるループに対しては効きません。なぜなら、バウンスメッセージは送ろうとしたメッセージとは「別の」メッセージであり、送る前ののヘッダは（本文には記録されているでしょうがヘッダとしては）残っていないからです。
つまり、「転送先からのバウンスを転送してしまった」というループは、厳密にはループじゃなく、次々新しいメッセージを作ってしまっているのです。
.forwardや.qmailは転送しようとしてエラーになったら元々の送信者にバウンスを返して終わりですから、この手のループは通常は生じません。
なお、普通のループにせよバウンスによるループにせよ、ループの経路にあるマシンのうち一番メール転送が遅いもののフルスピードでメールが送られることになります。大学ローカルでループが起きると、ウィルスチェックをしていて、つねに大量のメールを処理しているセンターのハブの負荷がたいてい最初に限界に達します。
投稿者 M : 2007年06月12日 11:13
>> M さん
仰るとおり、単純ループとバウンドによるループをごっちゃにしていました。
バウンドによるループに関する検証を行いたくても環境を準備するのが面倒…。バーチャルマシン上でやれば出来るかな。原理的には、基メールの MessageID がバウンドメールに含まれていれば、ループを制御できるような気がしています。
大量のパケットが流れるので、スイッチとかの負荷も高そうですね。似たようなもので、クローラの HTTP リクエストを投げたままサーバがダウンしてしまい、パケットを受け取るサーバがなくなるとスイッチが落ちるという現象が発生したことがあります。
投稿者 ceekz : 2007年06月13日 13:57
> 検証を行いたくても環境を準備するのが面倒
工夫してみると面白いと思います。VM使うと強制停止や復旧が簡単かもしれませんね。
> 原理的には、基メールの MessageID がバウンドメールに含まれていれば、ループを制御できるような気がしています。
まあ、だいたいそれで良いかもしれません。厳密にはMessage-IDは必須フィールドではないですが（スパムには、ついてないのも多いです）。保守的には、バウンスっぽい送り主（MAILER-DAEMONとか）だったら転送しない、とするのでしょう(procmailだと^FROM_DAEMON)。
> 大量のパケットが流れるので、スイッチとかの負荷も高そうですね。
実はメールの場合だとたいしたことないです。やってみれば分かりますが、メールトラフィックの律速段階はファイルの同期的書き込みです。HDDの最大スループットより一桁遅い速度しか出ません。せいぜい数十Mbpsでしょう。
投稿者 M : 2007年06月13日 17:14