Postfix-2.3でsleep中に切断されたらすぐに終了するパッチ

　Starpitなど、遅延を使ってスパム対策などを行っている場合、すぐに処理が終了しないため、smtpdプロセスが増加します。
　Starpitでは経験的に、普段起動しているプロセス数の2倍〜3倍程度になるようです。

　負荷の少ないメールサーバではほとんど問題となりませんが、受信するメールが非常に多いサーバの場合、プロセスの増加がメモリ消費などの点で(増加したプロセスはsleepしているだけなのでCPU負荷的には問題にならない)問題になることがあります。

　そこで、遅延している間に相手が接続を切ったら、こちらのsmtpdもすぐに終了するようになるパッチを作成しました。
　Postfix-2.3.x (最新 stable)に対してのパッチです。

http://k2net.hakuba.jp/pub/postfix-sleep.patch

(追記)
　Postfix-2.2.1 対してはLukeさんが下記で配布いただいています。
http://blog.dyndns.tv/~luke/archives/postfix-2.2.1-sleephack.diff

　このパッチにより、Starpitによるプロセス増加が遅延60sの場合で1.5倍ほどですむようになります。
　または、Starpitにより増加したプロセス数を、遅延90sで40%程度、遅延60sで70%程度に減らすことが出来るようになります。
　

(追記)
　このパッチを当てたPostfixでStarpitを導入された方は、できればsmtpdの平均プロセス数を導入前後で測っていただき、レポートいただけないでしょうか。
　「ps ax|grep smtpd|wc -l」とかをcronで定期的にとっていただければありがたいですが、気がついた時に何回か測っていただいた平均程度でもかまいません。
　こちらのコメントか、プロフィールのアドレスまでメールください。

　また、このパッチを当てることの副効果として、どれだけ遅延が掛かかったときに切断されたかをログに残すことが出来ます。
　それにより、スパマーがどのくらいのタイムアウトに設定しているのか客観的な情報を集めて、遅延時間を決めることが出来るようになります。

　先日からこの週末あけまでにかけて、2つのまったく別の環境で運用された、パッチを当てたPostfixのログを採取できました。

　sleep中に切断やこちらの反応前にDATAなど送ってきた場合、下記のようにログに残ります。(新パッチ版)

Jul 28 06:37:23 misorano postfix/smtpd[28066]: NOQUEUE: sleep: RCPT from 84.95.125.108.cable.012.net
.il[84.95.125.108]: lost connection after 30 sec; from= to=<*****@hakuba.ne.jp>
proto=SMTP helo=
Jul 28 06:41:54 misorano postfix/smtpd[28147]: NOQUEUE: sleep: RCPT from unknown[220.90.32.5]: pipel
ining after 59 sec; from= to=<******@hakuba.ne.jp> proto=ESMTP helo=
Jul 28 06:43:11 misorano postfix/smtpd[28144]: NOQUEUE: sleep: RCPT from unknown[61.77.50.2]: lost c
onnection after 10 sec; from= to=<******@hakuba.ne.jp> proto=SMTP helo=

この「lost connection after 30 sec」などの「30」が、sleep開始してから何秒後に切断などが行われたか、という秒数になります。

　下記にその結果を添付します。
　秒は遅延を開始してからの時間を10秒毎に四捨五入した時間帯で、LC数が途中でlost connectionとなった数、PL数がこちらの返答前にDATAコマンドを送ってきた数、です。
　切断検出率は、このパッチによりクライアントからの切断が検出できた割合です。これは、closeやshutdownが行われずに接続が切れた場合は、このパッチでは切断の検出ができないためです。

【環境A】

切断検出率	80%



秒	LC数	PL数	%
0	62	82	7%
10	131	1	7%
20	310	4	16%
30	805	101	45%
40	201		10%
50	57	2	3%
60	84	98	9%
70	1		0%
80	3	2	0%
90	70		3%

総数	2014	
35秒まで	1496	74%
45秒まで	1697	84%
65秒まで	1938	96%

【環境B】

切断検出率	85%



秒	LC数	PL数	%
0	234	655	4%
10	7737	369	37%
20	2185	68	10%
30	5663	392	27%
40	113	9	1%
50	708	32	3%
60	1131	1705	13%
70	46	14	0%
80	36	5	0%
90	928	102	5%

総数	22132	
35秒まで	17303	78%
45秒まで	17425	79%
65秒まで	21001	95%

【環境C】



秒	LC数	PL数	%
0	75	281	7%
10	325	46	7%
20	623	13	12%
30	2594	342	56%
40	155	8	3%
50	366	7	7%
60	163	283	8%

総数	5281	
35秒まで	4299	81%
45秒まで	4462	84%
65秒まで	5281	100%

【環境D】

秒	LC数	PL数	%
0	293		1%
10	5447		24%
20	712		3%
30	15607		69%
40	351		2%
50	174		1%
60	101		0%
70			0%
80			0%
90			0%

総数	22685		
35秒まで	22059	97%	
45秒まで	22410	99%	
65秒まで	22685	100%

【環境E】(lukeさんのブログ参照)
http://blog.dyndns.tv/~luke/blog/?date=20060731

　この結果から、多くのスパマーは10秒や30秒以内の短いタイムアウトを設定して送信していることがわかります。(環境A/Bの傾向の違いは、届くスパム種類以外に、sleep以外に掛けている制限の違いによるものも考えられます。)
　遅延は65秒ほど掛ければ現在のところ十分で、遅延によるプロセス数の増加などがどうしても問題になる場合には、35秒ほどでも遅延による効果の7割以上が得られる、ということがわかりました。
　90秒にも山がありますが、これは特定の送信元と考えられるため、このスパム業者らしい接続要求に対してのみ、特別に長めの遅延を掛けるか、確実に特定できるならそのままRejectするようにしたほうがよいと考えられます。

(追記)

和歌山大学システム情報学センターの吉田さんより、最大3分(180秒)でのログをいただきました。
モーグルとカバとパウダーの日記 - taRgreyのtarpitting時間について
この結果から、(Starpitではなく)taRgreyでは125秒程度のtarpittingがよいのではないか、と考えられます。

　このパッチ作成に際して、Postfix-MLで質問させていただき、助言やアイデアをいただきました。
　また、動作確認やログの収集について、長野で働く専務のblogの高村さんと、佐世保高専でスパム対策をされている中原さん、某企業でネットワーク管理者をしている友人、に協力いただきました。

　この場を借りてお礼いたします。ありがとうございます。

(追記)

うちのサーバで何日か安定して動いていたため、パッチを接続元IP,HELO,MAIL FROM,RCPT TOもログに表示するものに修正しました。
これで例えば、誤検出があったときに追うときにも、使いやすくなったと思います。
2.3.0と2.3.1で動くことを確認しています。
新しいパッチだと、コンパイラによってはコンパイルが通らない場合があるようで、修正予定です。情報ありましたらコメントにいただけると助かります。