\ay diary

サーバを止めたついでにIMAPサーバをCyrus 2.1からDovecot 1.0.8に変更した。etchのdovecotパッケージはちょっと古そうだったのでsidからバックポートした——というか、再築構して使った。メールボックスの変換はcyrus2courierを使った。このツールはDovecotにも対応している。

同ツールはskiplistなseenデータベースには対応していないということなので、ツールを実行する前にcvt_cyrusdbを使ってテキストに変換しておく。

# cvt_cyrusdb \
    /var/lib/cyrus/user/a/akira.seen skiplist \
    /tmp/cyrus-seendb/akira.seen flat

その上で以下のようにツールを実行した。

# cyrus2courier \
    --dovecot --hashed=s \
    --seen-dir=/tmp/cyrus-seendb \
    --subscribe-dir=/var/lib/cyrus/user \
    /var/spool/cyrus/mail/a/user \
    /tmp/dovecot-dir akira

オプションを除いた一つ目の引数はCyrusのメールボックス用のディレクトリなのだけど、階層化されているのでこんな指定になった。何かオプションなりなんなりで対処できるのかもしれないが、調べていないのでわからない。アカウントは数個だったのでいちいち指定して作業を終えた。

未読情報やフラグについては引き継いでくれるようなのだけど、キーワードについては引き継いでくれなかったようで、自作のメール振り分け・spam処理ツールが処理済みのspamメールをもう一度処理しようとしだしてちょっとまいった。

メールを処理するスクリプトのexpireの設定を変えて再起動したところ以下のような感じのエラーになった。

open: user akira opened INBOX.Junk
SQUAT failed to open index file
SQUAT failed
Fatal error: word too long

てっきりメールボックスが壊れたものだと思って(何度か壊れたことがある)cyrus.{cache,header,index}を削除してやり直したら、今度は単にメールボックスにアクセスできなくなった。たしかメールボックスを作り直すツールがあったよなとcyrreconstructを試すも、どうにもうまく動いてくれない。どうもメールボックスの指定方法が悪いらしい。いろいろ検索してみたりもしたのだけど、結局、試行錯誤の末に以下のコマンドラインで削除したファイルを再生成できた。

cyrreconstruct -rf user.akira.Junk

これで一安心と思ってスクリプトを再起動したら、なんとまた同じエラーが。今度はエラーメッセージ自体を調べてみたら、なんのことはない、IMAPコマンドが長すぎるという意味だった。とりあえず、一度に削除するメッセージ数をある程度以下にするようスクリプトを変更したところ、ようやくきちんと動くようになってくれた。

ちなみにSQUAT failedのほうはIMAP SEARCH用のインデックスファイルがないという意味で、これはそのようなインデックスを作っていないのなら無視してよいらしい。あるいはsquatter(8)を使ってインデックスを作っておくとIMAP SEARCHでそれが使われるようになるらしい。ただし、新しくメッセージが登録されてもインデックスは更新されないようで、cyrus.confのEVENTS { ... }で定期的にインデックスを再構築しなければならないとのこと(更新ではない)。

先日から少しずついじっているimapfilter.rbがだいぶ形になってきた。

今のところ一次受けメールボックスをスキャンして、振り分けルールと迷惑メールのチェックルールを実行して、その結果を受けての各種振り分け(やコピー)を行うことができる。また、迷惑メール用メールボックスへの投入→迷惑メールフィルタに登録、同メールボックスからの削除(+FLAGS \Deleted)→迷惑メールフィルタからの削除といったこともできる。メールボックスを指定することでバッチ的に振り分けを行うとかもできるはず。

まだdaemon化ができるようにしていないのでそれをするのと、コマンドラインからルールのexclude/includeを指定できるようにするといったあたりが近々のToDo。IDLE、NAMESPACE、UIDPLUSへの対応が少し長めのToDo。UIDPLUS(というかUID EXPUNGE)は早めに対応したほうが良さそうかな。あとはbug出しも必要か。

RubyForgeあたりに突っ込むと使ってくれる人がいたりするだろか? (あいかわらずお粗末なコードでだいぶはずかしいが)

一時的にとはいえcyrus環境にしたせいでメールの取りまわしが面倒なことになってしまった。しょうがないのでIMAPメールボックスをスキャンしてあれこれするスクリプトを書いてみた。

一時cyrus環境に戻しているのだけど、振り分けとかフィルタリングとかの面倒くささに直面してximapdはやっぱり便利だったなあとしみじみ思う。sieveとか、imapfilterとか、どうもね。MUAのルールなんかも大量になると管理が大変だし、複数の環境からアクセスするとなると使いにくい。

久しぶりにXimapdのコードを書いた。IMAPのタグなし応答がそれなりに送られるような雰囲気のものにしてみたつもり。といいつつテストが追いついていないというのがダメなんだけど。

せっかくの前田さんのコードに対し、どうも私が場当り的に手を入れてしまっているのでここらで少しコードを見直さないとまずそうな気も。一通り終わったらバックエンドをいじるか作るかしないとなー。

久びさに見てたらバージョンが上がっていたのでちょっと試しに動してみている。

認証がLOGINのみというのは相変わらずなのだなあ。あと、charsetのこと考えてないっぽい。まず検索がダメなのはともかくとして、わけのわからない文字コード(特にヘッダ)で届いたメールをRDBに投入するときの動作のこととかもあんまし考えられていないような気がする。勘違いかもしれないけど。

無理矢理使えるようにするとしたら…… UTF-8かなんかに変換したのを入れておくテーブルを追加する、とかになるのかな? あるいはMySQL本体で日本語的にまともなFULLTEXT検索を提供してくれるのを待つとか? PostgreSQLだとどうなんだろ。

ximapdのバックエンドにHyper Estraierを指定しているのだが、属性のいくつかにインデックスを付けたところ素晴らしい効果を得られた。ここのところ忍耐が一つのキーワードになっていたのだが、これによって普通に使えるレベルに持ち直した。メールの登録や移動は遅くなるのかなと思ったが、気になるほどではなかった。後で簡易の計測くらいはしてみようかなと考えているが、まあ、少し後で。

いろいろあって今のところ登録されているメール数がそれほど多くないため、今後どうなるかもう少し見ていきたい。

ximapdのバックエンドにSennaを使えないかなと考え中。

Sennaのクエリーの書式によると数値の大小を条件とすることができないっぽい。IMAPには日付けとサイズに関して大小条件を指定できることになっているからここらへんをどうするか考えないとならない。さて、どうするとよいのかな?

ximapdをバージョンアップし、ついでにバックエンドをHyper Estraierにしてみる。

hyperestraier.debはukaiさんのところからもらってきて、パッケージにないrubynativeだけ自前でコンパイルした。ただいまximapd --import中。