一周まわってprocmail+bsfilterに戻ってきた日

自宅メール環境でどうもSpamAssassinの学習具合いが悪い。何度覚えさせてもすりぬけてくるspamがある。そもそも以前はbsfilterを使っていたのだが、マシンがクラッシュした際に、ふと思いついて構成を変更したのだった。SpamAssassinをどうしても使いたいわけではないのだし、元に戻すことにしよう。

あ、そういえばmilterを作ってみたいと思っていたのだった。というのを思い出したので、milter-manager付属のツールキットのチュートリアルを読んでコーディング。ちょこっと変化が出てきているのに軽くはまったりながらも、一応の動きを見られるところまでは作ることができた。require 'milter'はrequire 'milter/client'になったということでいいのかな。

割り合い順調だったのだが、local recipientのspam判定データベースをどうやって参照させるのかな、というところで詰んでしまった。詳しく知らないのだけどmilterのレイヤではそんなことできないっぽいのかな。そんな気はする。spamass-milterのコードをざっとながめてみたけれど、ad-hocなことをやっているようで。そういうことか、と。

ただ、よく考えてみると、milterレイヤでspam判定させたとしても判定結果をもとに(特にSpamAssassinやbsfilterのような判定で)メールをrejectするのもあまり現実的ではない。せいぜいヘッダを入れるくらい。つまり、そもそもmilterの線はナシ気味だったんだとここにきて気付く。なんというか、いろいろ残念。(私自身が。)

もう一度最初から整理しよう。

dovecotに投入するタイミングで判定と振り分けができれば、dovecot-antispamとの組み合わせで十分に運用できる。とすると、投入時のアクションをどうにかすればよい。sieveか。で、sieveにあたってみるが、spam filterなんかはexperimentalらしいと知る(これを調べるのも何度目になるんだか)。じゃあMDAに渡すところでパイプをかますようなdovecotのdeliverのwrapperでも書くかとか、以前使っていたIMAP的に処理するプログラムを引っぱり出すかとか、あちこちうろうろ。

そうして、結局、procmailからbsfilterとdeliverを呼ぶのが楽なんじゃないかという結論にたどり着いた。たくさんのユーザがいるわけでもないのでちまちま対応していけばよいし、ユーザによって選択できるのもそれはそれでよい。

なつかしのprocmailはやっぱりなつかしく。変わってないっぽいけれどももうほとんど忘れてしまっていてmanページからコピペするなどして設定を終えた。