_ 非常ベルが鳴る。火災発生。避難せよとのアナウンスがビル内に響きわたる。
_ だが、わしはサーバのメンテナンス作業中で、中途半端な状態で放置して避難するわけにはいかない。
「おれはここに残るっ！ みんなは先に逃げてくれ！」
「バカなことを言うな、おまえひとりを置いていけるか！」
「しかしこいつを始末せずにここを離れるわけにはいかないんだっ！ 時間はないっ！ はやく！」
「やまやーーーっ！」
「ぬおぉぉぉっ」_ ……というイベントが本日リアルでありましたが、無事生還しております。っていうか、ただの避難訓練だし。
_ 少し前からぽちぽちといじってるんだけど、うーん、なんか、びみょー。web ui は充実してるし、この手のアプリでは今までなかったことに自前のキューを用意してメールの消失に備えてたりするところはひじょーに好感が持てるんだけど、昔ながらの思想で作られてるところも多くてうれしくない。
_ つーかさー、今どきバーチャルドメインに対応してないってどうなの。ドキュメントには こんな節があっていかにも対応してます、ってな風だけどさ、実際やってみたら hoge@example.com と hoge@example.jp が異なる ML として併存できないんでやんの。それ仮想ドメインに対応してるって言わないでしょ。そんな中途半端なのを使うのはかえって不幸の元になるよ。
_ 昔ながらのメーリングリストって、メンバー管理とかアーカイブとかシーケンス番号の管理とかのストレージまわりの都合で、ひとつの ML を複数のホストで分散処理することができないんだよね。冗長構成にしたくても、active/active ではなく active/standby にして定期的に同期するってな構成にするのが関の山。最近ならば RDBMS とか LDAP とか当たり前に使われてるんだから、そういうのを利用してこの欠点を克服したいところだけど、mailman はわりと最近になって開発されたもののくせにそういうことはまったく考慮していないようだ。どうやって ML サーバの可用性を上げようかというのは大昔から誰もが持ってた悩みだったと思うんだけど、それにちっとも答えてくれない。
_ 世の ML マネージャはほとんどみんなそうだから、mailman だけを責めるのは筋違いかもしれんけどさ、majordomo や fml なんかに比べたらずっと後発なんだから、そういう欠点は解消しておいてほしいよね。mailman は一昔前のものに比べたらたしかに進歩してるけど、それでも今の観点で見たらまだまだ古くさい、と言わざるを得ない。だからといって mailman 以外のものはもっと古くさいわけで、現実的にはこれがいちばんマシというのが悲しいところ。ええ、だから使いますとも。めんどくさい手間かけて。つーかみんな困らんのか？ 疑問に思わんのか？
_ DNSリゾルバのニューフェイス「Unbound」という記事より。
しかしUnboundのインストールには、開発環境のインストールが必要なこと、起動スクリプトが用意されていないことなど、いくつかの課題点が浮かび上がってきます。本気で噴いた。
この課題を改善するため、筆者を含む有志数人は「日本Unboundユーザ会」を2008年9月に立ち上げ、(以下略)
_ 買い物したらお釣りが二千円札で返ってきた。ずいぶん久しぶりだなー、この前見たのいつだっけ、と思い出してみたら、そういえば前回も同じ店で買い物したときのお釣りだった。どうやら釣り用に二千円札を大量備蓄してるよーだ。
_ つーか自販機で使えないのでうれしくないんだが。
_ ひきつづき mailman と格闘中。
_ そういえば最近は DKIM 署名されたメールもぼちぼち出てきたなー。その9割以上は gmail 発なので、DKIM に対応してるサイトが増えたわけじゃないんだけどね。
_ で、ML はメールをいろいろ書き換えちゃうので DKIM/DomainKeys と相性が悪い。それはいろいろアレなんで、元の DKIM-Signature は残さん方がいいな、と思っていろいろ調べてたら、そもそも mailman はそれがデフォルトだった。なかなかえらい。
_ なんだけど、mailman はなぜか DKIM-Signature、DomainKey-Signature だけでなく、Authentication-Results まで削除するようだ。いろいろ考えてみたけど理由がわからん。mailman の後で判定が失敗するのを防ぐために DKIM-Signature を無効にするのはわかるんだが、mailman に入ってくる前までに判定された Authentication-Results を消す意味がわからん。調べてみたら mailman 2.1.9 までは A-R はいじらない。2.1.10 から。履歴をざっと見てもそういうふうに変更したよとあるだけで、なぜそうしたのか書いてない。どっかで議論されたのかもしれないけどそこまでは調べてない。
_ わからんので、mailman の処理は無視して A-R は素通しするようにいじった。せっかくなので元の DKIM-Signature は消すのではなく、X-Original-DKIM-Signature と書き換えるように修正。
_ mailman 関連で調べものしてたらたまたま Gmail は重複した Message-ID を受け付けないという話を見つけた。cyrus-imap も同じような挙動をすると聞いたことはあるけど、gmail もそうだったんか。知らんかった。
_ いちおう RFC 的には message-id はユニークじゃなきゃいけないことになってるけど、「付けるならユニークにしとけ」であって、実は message-id の存在自体が MUST じゃないからこれでメールの一意性を確保するのはムリだし、複数の相手に送信したり転送したりで元がユニークでも最終的には同じ message-id を持つメールが複数同時に存在しうるので、受ける側でこういう制限をかけちゃうのはあんまりよろしくないと思う。メールじゃなくて NetNews ならそういう仕様でいいんだけどね。あれは複数のサイトから同じ記事が流入するのを防ぐために必須だから。
_ ちなみに ML が元の message-id をそのまま使うというのは majordomo でも fml でも同じで、mailman に限ったことではない。とはいえ、みんなそうだからこの動作が正しいんだというわけではなく、エンベロープやヘッダ(場合によっては本文も)を書き換えて送りなおすという処理をする以上、元のメールと同一ではないのだから新たにユニークな message-id を付け直すというのが正しい動作だろう。やらないのは間違ってるよね。そういう意味では received もいじった方がいいのかも。
_ でも、あー、メンテの手間を考えたらパッチはできるだけ減らしたいんだよな。すでに何ヶ所かいじってるから、今さら1ヶ所増えたところで大した違いはないんだけどさ。よそのサイトもみんなそれで動いてるわけなので、このせいで gmail ユーザからクレームがあったとしても、上の考察はまったく無視してそんなのうちじゃなくて gmail に文句を言ってくれ、で済ませておいても許されそうな気がする。ええ、わしの職業倫理なんてその程度ですよ。つーことで、放置。