2.1. SMTPトランザクションの遅延

内部行きのSMTP通信にトランザクションの遅延をはさむことが、 スパムを止めるのにかなり効果的だということが判明している。 これは タール坑法[1] (http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html を見てほしい) の素朴な形態である。

多くのスパムと、ウィルスが生み出す電子メールのほぼすべてが、 大量のメールを極めて短時間で送信できるように最適化された特殊なSMTPクライアントソフトウェアを使って サーバに直接配送される。 このようなクライアントは一般にラットウェアとして知られる。

この仕事をやり遂げるために、ラットウェアの作者はたいがい近道、 というか、RFC 2821 仕様からの若干の "逸脱" をしようとする。 ラットウェアならではの特徴として、それが名うての短気者であるということがある。 特に、ゆっくり応答するメールサーバに対してそうだ。 サーバが最初のSMTPバナーを示す前に HELO コマンドや EHLO コマンドを発行したり、 サーバが PIPELINING 機能をまだ広告していないのに SMTPコマンドをパイプラインしようとしたりする。

ある種のメール転送エージェント (Eximのような) は、 このようなSMTPプロトコル違反を自動的に同期エラーとして扱い、 即座に外部からの接続を切る。このようなMTAを使っていれば、 ログファイルにはこの効果によるエントリが多数現れていることだろう。 事実、 最初のSMTPバナーを表示するのに先立って時間のかかる検査 (DNSによる検査のような) を実施しているときは、 ラットウェアクライアントであればサーバが活動を始めるのを待たないから、 このようなエラーが頻繁に起きる (こういうことをするのは、スパムを送信しようとする者だ)。

さらに遅延をはさむことも役立つ。例えば、 次のようなときに待つようにすることもできる:

20秒という数字はどこから来たのだろうか。なぜ1分とか数分ではいけないのか。 RFC 2821 は、送信側のホスト (クライアント) が SMTP応答ごとに数分は待たなければならないと定めているというのに。 問題は、受信側のホストによっては (特に Exim を使っているものでは)、 外部から来るメールの配送の試みへの応答の際に 送信者呼出し確認法を実行するものがあるという点だ。 ユーザがこのようなホストにメールを送ると、ドメインのメール交換機 (MXホスト) に接続して、 送信者アドレスを確認するためのSMTP通信を始める。 このような送信者呼出し確認法の既定のタイムアウトは、30秒である --- この長さまで遅延をはさむと、相手の送信者呼出し確認法が失敗してしまい、 次に、ユーザからの元々のメール配送が拒否されるおそれがある (普通は一時的な失敗なので、メッセージの配送を5日くらい再試行することになり、 メールは最後には送信者に返送される)。

言い替えると、20秒というのは、 真っ当なメールの配送を妨げることなく足留めしておけるほぼぎりぎりの長さなのだ。

このような遅延をすべてのSMTPトランザクションにはさみたくないときは (サイトが非常に多忙で計算機の資源が少ない、といったときだね)、 "選択的な"トランザクションの遅延にすることもできる。 この場合は、次のようなときに遅延をはさむ:

実際は、選択的なトランザクションの遅延は、 以下の節で議論するあまり決定的でないいくつかの検査と併用するのに いい方法かもしれない。 例えば、SPEWS ブラックリストの結果を見て即座にメールを 拒否したくはないだろうが、その結果がやっかいごとの徴候をはっきり示していれば、 トランザクションの遅延をはさんでみてもよいだろう。 そうしたとしても、 真っ当なメール配送であれば、わずかに遅延を余儀なくされるほかは影響を受けない。

逆に、スパム送信の決定的な証拠 (例えばSMTPでの検査での方法によるもの) が見つかり、サーバに余裕があれば、 最終的に配送を拒否する前に、より長い遅延 (例えば 15分くらい) をはさむこともできる [2]。 スパム送信者は、DNSブラックリストや他の協調型ネットワーク検査に追いつかれるまでに できるだけ多くの人々を探索しようとする。 SMTPトランザクションの遅延はその歩みをほんのわずか遅めるが、 それ以外にはたいして得になることはない。 いわば、純粋な利他の行ないだね。:-)

私自身の場合、選択的なトランザクションの遅延とSMTP同期エラーとで、 外部からの配送の試みの 50% 近くを拒否できている。 これは大雑把に言い替えると、外部から来る不要メールの 50% 近くは SMTPトランザクションの遅延だけで止められる、ということだ。

スパム送信者が適応してきたら...も見てほしい。

Notes

[1]

[訳注] teergrubing --- ドイツ語 Teergrube (タール坑) より。 tarpitting --- 英語 tarpit (同意) より --- と表記している文献もある。

[2]

外部から来るSMTP配送を保持している間は、 サーバのTCPソケットやメモリなどのサーバ資源も保持しているのだということに気をつけよう。 一般に多忙なサーバでSMTPトランザクションの遅延をはさむと、 サービス不能攻撃に対する脆弱さを増すことになる。 より "スケーラブル" な選択肢も考えられる。 送信者がラットウェアクライアントであるという決定的な証拠をつかんだら すぐに接続を切る、というものだ。