Linux: 2006年8月アーカイブ

前のエントリで少し毛嫌いしてたけども、 Starpit の手法であれば「まだマシ」かなぁと思った。 greylisting では確実に該当 IP からの一発目のメールが遅延してしまうけど、こっちならば遅延はない ( その代わりにサーバの初期応答が 1 分半ほど遅れる ( 応答遅延時間は設定による ) ) 。
ただ問題なのは、ここで述べられているけど、 Postfix 本体でこれを実現しているので、 RCPT TO 単位で tarpitting が起こってしまう。つまり 1 通のメールだったとしても宛先が 10 件あれば、 90 秒の tarpitting だとすると、全ての宛先に送りきるまでに 15 分待たされてしまう。
この構造的にまずい点については、postgrey による greylisting のように Postfix の filter で実現できるといい感じらしい。 この考えを取り入れた taRgrey というハイブリッドな手法にすれば、これらの弱点は克服できるそうだ。ふむふむ。しかしまだこの手法に対する実装は無いとのこと。

ここまで調べて、うちの鯖に実装するなら taRgrey だなぁと確信…。
taRgrey なら、まずスパムのほとんどは tarpitting によって阻止可能。この部分の設定はメンテナンスフリー。
スパムではないのに tarpitting で接続が切れてしまったものに対しては greylisting で救済する。この部分の設定は、ホワイトリスト & ブラックリストのメンテナンスが必要だが、そもそも tarpitting での誤検出はごくまれらしいので、単体で greylisting するよりもメンテナンスが容易 ( なはず ) 。
S25R に該当する正当なメールに対して tarpitting してしまっても良いのであれば、ホワイトリストのメンテすらやらなくて良い ( はず ) 。

うーん、やっぱり「メンテナンスフリー」は大事ですよ。
単体の greylisting なんて、趣味の自鯖では到底やろうとは思えない。いや、むしろ仕事なら尚更かも。
taRgrey の実装が待ち遠しい今日この頃です。

自宅サーバでダイナミック DNS を使ってメールサーバを活用しようと思い立ったので、 Spamassassin とかいじってみる。

下記、 /etc/procmailrc の記述：

  PATH=/bin:/usr/bin:/usr/local/bin
  MAILDIR=$HOME/Maildir
  DEFAULT=$MAILDIR/
  LOGFILE=$MAILDIR/procmaillog
  LOCKFILE=$HOME/.lockmail
  SPAM=$HOME/.spam
  
  # at first, check 'X-Spam*' and filter
  :0fw
  *!^X-Spam.*
  |spamassassin
  
  # already filtered, then send to '.Spam' folder
  :0
  * ^X-Spam-Status: Yes
  $MAILDIR/.Spam/

こうしとけば、 IMAP で繋いだとき、スパム判定を食らったメールは自動的に「Spam」フォルダに入る。
判定漏れで INBOX に入っちゃったものはメーラ上で手動で Spam フォルダへ移した上で

  # SPAM 学習
  /usr/bin/sa-learn --spam /home/*/Maildir/.Spam/cur
  # 非 SPAM 学習
  /usr/bin/sa-learn --ham /home/*/Maildir/cur

とか定期的にやっとけば後は手間要らず。のはず。 cron に入れておけばさらに手間要らず。
もう少し突っ込んで Web 上を調べてると S25R とか greylisting とか tarpitting ( greet pause ) とか面白そうな技術も発見。
これって、とりあえず怪しい IP やドメインを正規表現ではじいて、そいつらからのメールはとりあえず応答を遅らせてみたり reject してみたりして、それでもちゃんとメールサーバの作法通り再送してきた奴だけは許可します、っていう仕組みなのね。
確かにこれでいけば「スパムうぜえ！」って思うことは少なくなるだろうけど、「応答を遅らせてみたり reject したり」はしたくないなぁ。そんなヘンな挙動が「当たり前」にはなってほしくない。
というわけでこれは今回は見送ったけど、そうは言っても「とにかくスパムを受け取りたくない」って人には効果抜群なわけで、なんだか有名になりそうなのが微妙...