朝、会社へ行ったら、社内の顧客管理用メールサーバで昨晩からメールが取得できてないとか。
ログ見たら、fetchmail というメール取得プログラムで SIGPIPE のエラーが出ていた。
問題のメールはSPAMメールのようだったので、取得元のメールサーバにThunderbirdのIMAPで接続して、メール削除してフォルダの「最適化」をやり、これでメールが削除できているはずなのだが、反応が鈍い。
Thunderbirdが応答しないので、しょうがないから、fetchmail を再度実行するも、亡霊のごとく、ログにはそのSPAMメールのFrom行が出てくる。
telnet で取得元の port 110 叩いて、POP3プロトコル手打ち。
RETR 1ってやると削除されてねえし orz
ThunderbirdでIMAPのexpungeが完全に実施されていなかったようだ。
で、DELE 1ってやったら再び応答しなくなる。
メールで顧客情報管理なんかやってるから、やたらとクソ重くてやってらんね。
で、そのメールを手動でフォルダに移動させて工程管理だから、紙を回してるのとやってる事は変わらないし、情報化とは程遠い。そもそも基幹システムがしっかりしてたら、客のメール回すなんて馬鹿げた事はやらなくても済む話。
ああ、イカン。トラブル対応でゲンナリして愚痴っぽくなってしまったな。
で、メール取得元サーバにログインして、ハングってるpop3dをkillして、一応、telnetのPOP3プロトコル手打ちで、メールが消えてるのを確認して、fetchmailを実行したら復旧した。
問題のメールは消してしまったが、転送設定で他のアカウントにもコピーが残るように冗長化されてるので、そのアカウントから発掘してソースをじっくり眺めてみた。
multipartのクソSPAMだが、そのpartの一部に、行頭がピリオドで始まっていた。
SMTPのDATAのお約束として、行頭ピリオド＋改行でデータ終了の意味となり、fetchmailはそれを取得する際に、それでメールは終わりと判断するので、取得失敗となるようだ。
しょうがないので、Cyurus IMAPdで、DB更新時に root のDBファイル作って書けなくなるのを復旧するログ監視プログラムにfetchmailエラー時にimapsyncで受信トレイをコピーしてコピー元削除するコマンドを組み込んだ。
fetchmailと違って、配送では無いので、メールの振り分けができないが、pop3詰まりになって、メール取得がストップするよりはいいだろう。