動的割り当ての蹴っ飛ばしかた
動的割り当てからのメールいりません
spamの送信元を見てみると、動的割り当てからのものが大部分です。
これは以下のような理由によるものと思われます。
- 自前のネットワークから送信するとISPから追い出されたり、身元がわかってしまったり、相手にブロックされやすく、ダメージが大きい
- 使い捨てのアカウントが容易に入手できる。(spammerの再契約を防ぐ対策がISPには求められます)
- セキュリティ意識の低い一般利用者が少なくなく、踏み台にされている(zombie, open proxy)
また、Virus/Wormも自分でSMTPを使って送信してくるものがあり、
このタイプは100%動的割り当てから接続をしてきます。
9割以上のろくでもないメールは動的割り当てのアドレスから送られてきているのではないかと思っています。
動的割り当てをブロックするだけで、9割以上のろくでもないメールは受けずに済みますから。
その1:ドメインで拒否
いちばんシンプルなのはドメインでの拒否です。rblsmtpdを使っているなら、
パラノイドチェック(tcpserverの起動パラメータ -p)をした上で、環境変数$RBLSMTPDを設定します。
=.dy.bbexcite.jp:allow,RBLSMTPD="dynamic allocation - use SMTP gateway of your ISP"
これをいちいち書くのはめんどくさいのでドメインをズラズラならべたやつを用意して、cdbを作るMakefileでついでに変換したほうが楽です
tcp.smtp: tcp.smtp.nolookup dyn-domain.txt
cp tcp.smtp.nolookup tcp.smtp
sed 's/^\([.a-zA-Z0-8-][.a-zA-Z0-8-]*\)$/=\.\1:allow,RBLSMTPD="dynamic allocation - use SMTP gateway of your ISP"/' dyn-domain.txt >> tcp.smtp
同じデータを使うMTAがいくつもあるならrbldnsdなどを使うほうが管理が楽かもしれません。
この方法の欠点は、fqdnの末尾からドット区切りの単位つまりドメインでしか比べられない点です。
動的アドレスであることを特徴づける文字列が先頭や途中にあると、うまくはじけません。
その2:fqdnに含まれる文字列で拒否
その欠点をカバーするための、fqdnにある文字列が含まれていたら、動的割り当てブロックと見なす
qmail-spp用の
baddomainstr pluginです。
[rcpt]のところで使ってください。
/var/qmail/control/baddomainstrに書いてある文字列にヒットすれば
動的割り当てとみなします(taballにサンプル入ってます)。
ついでなんで、HELOのパラメータも見ています。
rfc2821にはHELO/EHLOのパラメータを使ってrefuseするなと書いてあります。
だから、HELO/EHLOの直後では拒否しないし、それを拒否理由にもしません。:-)
おまけ機能として
- やたらとspamでみかけるHELO/EHLOのパラメータに、ドットがひとつもない
- HELO/EHLOまたは$TCPREMOTEHOSTのなかに一定数以上の数字が含まれる(とりあえず8つになってます)
がついてます。
使わないときはソースのdefine文を直接編集してください。
環境変数$BDS(なつかしい響き?)を見ていて
| $BDS | 動作 |
| なし | なにもしない |
| 0 | ログに記録のみ |
| 1 | 一時エラー |
| 2 | パーマネントエラー |
と動作が変わります。$RELAYCLIENTが設定されているときもなにもしません
注意したほうが良いこと
いずれにせよ、パーマネントエラーにはしないほうが良いです。
spamの場合は、ほとんど再送してこないので、spamに対する一時エラーの効果は
パーマネントエラーとかわりません。
誤判定がおきてもまともなMTAであれば再送してくるので救済もできます。
また、どんなspam対策をとる場合であってもホワイトリストを作っておくことは
安定した運用を行う上で重要です。
動的割り当て拒否に文句を言う人たち
直接送信している自宅サーバーの人の中には文句を言っている人もいるようですが、
ISPのMTAを経由して送信すれば済む問題です。
ISPがrelayしてくれないなら、それはISPのサービスの問題です。
なによりも、メールを受けるかどうかは、あくまでも受ける側のポリシーの問題であって筋違いです。
デメリットは、そういうサイトからのメールがスムーズに受けられないという点ですが、
受けたければまったく受けられないわけでもなく、SPFをちゃんと設定してもらうとか、
一時エラーで様子を見る(graylisting)とか、回避方法はあります。
問題の根本は、わけのわからないところから送る側にあるわけで、
そのデメリットを理解・受容して運用していない。代償も払いたくない。
だけど他サイトの運用ポリシーに口だしをするというようなところからメールを受けても
ろくなことないでしょう。
INDEX
Hiroshi Tsukamoto