週末に自宅へ帰ってきてはいたものの，ろくにいじる時間もなかったので放置気味になっていたが，そろそろメンテナンスを 本格的に再開することにした。
本来なら今日中にメインシステムを寮へ移転するつもりだったのだが，いろいろとトラブルがあって来週以降に延期。 平日に使えるまともなマシンがないというのは非常に痛い。Crusoe 600MHz のノート機なんかでは Web 巡回すら ままならない。日記もさかのぼって埋めていかねば……。
ちなみに，連休中に密かに Linux 2.6.5 になっている。
メンテナンス予定一覧。
Courier-IMAP 3.0.4 をインストール。
./configure --prefix=/usr --enable-unicode
で make; make install-strip; make install-configure すれば良い。
--sysconfdir=/etc しないとちょっと悲しくなる。
山のように configure オプションがあって，どれがメジャーなのかさっぱりわからないが， 適当に指定して make する。
./configure --prefix=/usr --with-apxs2 --with-mod_charset --with-openssl --with-zlib --with-ftp --with-iconv --with-imap --with-imap-ssl --enable-mbstring --enable-sockets --enable-sysvmsg --enable-sysvsem --enable-sysvshm
make test するとやばそうなメッセージが出るが，悪いのは gcc 3.4.0 だろうし浮動小数点の round が 少々違って php が困ることはないだろうから無視する（ぉ
===================================================================== TIME END 2004-05-23 12:20:29 ===================================================================== TEST RESULT SUMMARY --------------------------------------------------------------------- Exts skipped : 69 Exts tested : 18 --------------------------------------------------------------------- Number of tests : 592 Tests skipped : 191 (32.3%) Tests warned : 0 ( 0.0%) Tests failed : 2 ( 0.3%) Tests passed : 399 (67.4%) --------------------------------------------------------------------- Time taken : 48 seconds ===================================================================== ===================================================================== FAILED TEST SUMMARY --------------------------------------------------------------------- Bug #24142 (round() problems) [ext/standard/tests/math/bug24142.phpt] Bug #25694 (round() and number_format() inconsistency) [ext/standard/tests/math/bug25694.phpt] =====================================================================
postfix を停止した上で，スクリプトを拾ってきて 変換する。
procmail 3.22 に入れ替える。
make して，make install-suid するだけ。
main.cf の mailbox_command を書き換える。
mailbox_command = /usr/bin/procmail -a "$EXTENSION" DEFAULT=$HOME/Maildir/ MAILDIR=$HOME/Maildir
念のため iptables で外周 interface のポートを塞いでから postfix を起動し，テストメールが 正常に Maildir に配送されるか確認する。
/var/spool/mail にも0バイトのファイルができてしまうようだ（？）
/etc/inetd.conf を書き換えて qpopper を起動しているのをコメントアウト，killall -HUP inetd する。
うちでは /usr/libexec/pop3d-ssl.rc などに起動スクリプトが入った。設定ファイルは /usr/etc/pop3d-ssl に 入ったのでこれを編集（sysconfdir 等は指定すべきだったね）。
.key と .crt を cat して .pem にして TLS_CERTFILE に指定する。同様に imapd-ssl も編集。
なぜか UNIX パスワードファイルをそのまま読む方法がない困った仕様になっている（最近では shadow password の システムなんて残ってないのだろうさ）。
pw2userdb > /etc/userdb/users
して passwd/shadow を中間形式に変換し，
makeuserdb
すると /etc/userdb.* にパスワードファイルが変換され，Courier-IMAP から参照されるようになる。
起動は /usr/libexec/pop3d-ssl.rc start などとすれば良い（pop3d-ssl は 995/ssl しかサポートしないので， pop3d.rc start で通常の POP3d を別途起動する必要がある）。imap のほうも起動しておく。
SquirrelMail をインストール。
インストールといっても，apache から見えるところに展開して config スクリプトで設定変更するだけ。非常に簡単。
現在は日本語版というのはおそらく必要なくて，本家の SquirrelMail から 1.4.3RC1 をダウンロードしてコンパイルするだけで 動くはず。ただし，日本語メッセージカタログのコンパイルは必要（.po を作る手順）。
これで，https 経由でメールが読めるようになった（メールが読めるようになった……）。
ときどき SPAM のヘッダについている X-AntiAbuse ヘッダだが，SPAM でないメールでも付いている場合があるようだ。 いったいこの X-AntiAbuse ヘッダは何者がつけているのか？
なぜか google で "X-AntiAbuse" を検索しても情報がほとんど引っかからない。しかし，今日来た SPAM のヘッダを 見ていて Received の第1段目（つまり SPAM が通過した最初の MTA）が "Exim" であることに気づいた（他の X-AntiAbuse ヘッダ つきメールがどうなのかは知らない）。
最新の Exim のソースファイルをダウンロードして grep しても，X-AntiAbuse の文字列は発見できない（3.x，4.x ともに）。 しかし，google は Exim と X-AntiAbuse との高い相関を示している：
X-AntiAbuse Received の検索結果 約 2,780 件 X-AntiAbuse Received Exim の検索結果 約 2,370 件 X-AntiAbuse Received Postfix の検索結果 約 847 件 X-AntiAbuse Received sendmail の検索結果 約 118 件
このようなML投稿 もあるし， 他にも Exim で X-AntiAbuse がつかないようにする config の書き換え方ページがあったので， X-AntiAbuse はたぶん Exim が付加しているヘッダだと考えて間違いないと思うのだが……。
Apache の mod_proxy を使っていると，google 検索したときに「検索文字列が2倍体になる」「CGIなどが誤動作する」といった 怪現象をずっと体験していたのだが，google でそのような症状を検索してもなかなか見つけられない。
今日かなりがんばって検索した結果，2件見つけることができた。どうやら mod_encoding が悪いらしい。
mod_encoding が勝手に query_string のデコード・エンコードをしてしまうため，妙なことが起きるようだ。試しに mod_encoding を 外してみると怪現象は起きなくなった。
まぁなんにしろ，これで mod_proxy を安心して使えるようになった。しかし最終的には WebDAV 環境の整備まで進める予定なので， （Zope などを使わないのであれば）いずれ mod_encoding とは決着をつけるときが来るのだろう……。