ついこの間新年を迎えたと思ったのに，いつの間にか1年の12分の1が過ぎ去ってしまいました。この時期は何かと行事や雑用が多く，油断しているとあっと言うまに新年度になってしまいそうです。子供のころ，大人たちが「1月はいってしまう，2月はにげてしまう，3月はさってしまう」と言っているのを聞いておもしろいと思ったことがありますが，その表現を実感として感じる年齢になってきたようです。
Plamo Linuxの状況
諸般の事情で去年はメンテナンスリリースしかできなかったPlamo Linuxですが，新しいOSS環境に追従するためのバージョンアップを目指して，1月の中旬くらいからGCC-4.2.2やglibc-2.7，X11R7.3など最新の環境をいじりはじめました。当初はインストーラやパッケージ管理の仕組みの改善も含めた大規模な改修を目指していましたが，賞味期限が切れているソフトウェアの更新だけでもかなりな規模になりそうなので，まずは新しいバージョンのソフトウェアできちんと動く環境を整えることを目標に作業を進めています。
最近のX Window Systemや日本語入力システム（インプットメソッド）などをいじって感じるのは，外部のライブラリへの依存性がずいぶん高くなってきたことです。たとえばX Window Systemの場合，かってはライブラリの依存関係の管理やMakefileの生成などを行う専用のツールを含めた巨大なソースコード一式を用意して，外部環境への依存をできるだけ減らしていましたが，X11R7以降ではOSSで標準的なGNU autoconf/automakeの仕組みを導入すると共にソースコードを分割，モジュール化して，パーツごとの開発を容易にする方向に大きく変化しています。
従来のX Window Systemでは，メーカごとにさまざまに異なるワークステーション環境でも利用可能にするため，便利だけれどOSに依存する独自コマンドなどは使わず，UNIX互換環境ならば必ず存在するであろう最小限のコマンドだけを使ってかなりトリッキーな処理を行っていた部分がありましたが，OSSの便利なツールを前提とすることで，それらの見通しがずいぶんよくなった印象を受けます。
かってのX Window Systemは "make World" というコマンド1つですべてのソースコードをコンパイルしていきました。メーカごとに異なる各種ワークステーション環境の違いを吸収し，あらゆるUNIX互換OSに存在する最小限のSoftwaretoolsのみを使って環境を構築していくそのあり様は，まさに天地創造（make World）と呼ぶにふさわしい壮大で複雑なメカニズムでした。
一方，外部環境に大きく依存するようになった結果，X Window Systemのソースコードやドキュメントだけでは解決できないような問題も生じてきて，freetypeやD-bus，expatといった外部環境まで意識する必要が生じてきたのはディストリビューションのメンテナにとって頭の痛い問題です。読んだり調べたりしなければいけない資料はX Window Systemの世界だけに閉じていませんし，必要となる外部環境もどんどんバージョンが更新されて，旧来のやり方が通じなくなることもよくあります。
システムが進化していくにつれ，この種の高度で複雑な相互依存関係が生じることは避けられないでしょう。OSSの特徴である「バザール」モデルが，このような高度で複雑な相互依存性とどのように折りあっていくかは研究テーマとしても興味深いところです。
メールサーバのログ再考
Plamo Linuxの新版の話はまた改めて紹介することにして，今回は前回報告したメールサーバのトラブルとその対策についての後日談をとりあげようと思います。前回，メーリングリストのポリシー変更やメールキューの保持時間の短縮という対策を施したメールサーバですが，その後1ヵ月ほどのログファイルのサイズを調べると，図1のような結果になりました。
図1 Postfixプロセス別ログファイルサイズの変化
12/25ごろから急増しだしたsmtp，mailqの処理量（＝ログファイルのサイズ）も，1/6の深夜に施した対策が奏功したのか，約2日後の1/9にはmaiq, smtpともに12月上旬のレベルに落ち着いてきましたし，自分の関係しているメーリングリストの配送も遅延なく行われているようです。
この結果を見ると「問題が解決してよかったね」という感じですが，あまりに出来すぎのような気がして，もう少しログファイルを調べてみることにしました。
ワインバーグ先生が『ライト、ついてますか』の中で繰り返し指摘しているように「すべての解答は次の問題の出所」ですし，うまくいった解答ほど，次のより大きな問題を生み出しがちなことは今までに何度も経験しているので，今回の例のようにあまりに出来すぎな例には直感的な不信感を感じてしまいます。
まずは，メールサーバのログからメールを受信する役割を果たしているsmtpdのログを抽出した上で，1日単位で受信拒否件数と受信受諾件数を抽出してみました。前回紹介したように，このメールサーバではSPAMの受け取りを少しでも減らすために，ドメイン名の逆引きができないホストからの接続とローカルに存在しないアカウントへのメールは受信拒否するように設定しており，この条件で受信拒否された接続はログに'reject'と記録されます。一方，これらの条件を満してメールを受けつけた接続にはキューIDが割り当てられた上で'client=...'と記録されるので，これらをキーワードに用いて出現頻度を1日ごとにカウントしてみました。
図2 smtpdが拒否するメール（reject）と受け付けるメール（accept）のカウント数の変化
この結果を見ると，メールを受け付けた件数はこの2ヵ月間ほぼ2,000件前後で推移しているのに対し，受信拒否の件数は15,000から30,000件の幅で推移しており，かなりバラツキが見られることもわかりました。しかし，今回のトラブルが発生した12月末から1月頭にかけて特に目立った変化は確認できず，この時期にSPAMの流量が特に増加したというわけではないようです。
このグラフを見ると「アドレスが登録されている（逆引きができる）サーバ」から「ローカルに存在するアカウント」に対して送信する，という最低限のルー ルに限っても，それを守っているメール（accept）に比べて守っていないメール（reject）は10倍近くになっていることが見てとれます。もちろん，このルールを守っているメールでも10通のうち8通くらいはSPAMだったりするので，昨今のSPAM とHAM（受け取りたいメール）の比は100：1といっても過言ではないようです。
