薪ストーブのガラスを交換

薪ストーブのある暮らしについて書こうと思っているうちに時間が経ち、その最初がいきなり大きなトラブルのことになってしまいました。

今年(2015年)の初冬は暖かで、シーズン最初の火入れは例年より20日ほども遅く、11月も終わる頃。その2日め、「ピシッ!」という音とともに、ストーブ扉のガラスに、向かって左上から中央ほどまでヒビが入ってしまいました。火はガンガン燃えているし(だからこそヒビが入ったのですが)、どうしようと思っている間にまた「ピシッ!」と音がしてヒビは右下にまで達し、ガラスは2つに割れてしまいました。

この薪ストーブはもう20年ほど前のアメリカから個人輸入のもので、有名メーカーのものでもなく(いま調べてみるとこのメーカーの主力商品は焼却炉)、いまや廃番になっているようで部品として調達することはほぼ無理です。そこでまずはネットで「薪ストーブ 耐熱ガラス 交換」で検索しました。ほぼトップに出てくるブログ記事「薪ストーブのガラス交換」を読み、そこで紹介されているネット通販(これも先ほどの検索でほぼトップに出てきます)で入手できることがわかりました。そのサイトで簡単に見積りをとることができます。電気硝子建材の「ファイアライト」(5mm厚)が耐熱800℃と薪ストーブ向きで、うちのガラスは 400mm×250mm ほどの大きさなので、1万円強になりそうです。

扉をあけて内側から見たところ
ただ、形状が簡単な長方形ではなく、上辺が丸くカーブしています。加工料もいくらか上乗せになりそうですし、何しろこれを正確に伝えなければなりません。せいぜい 1mm ほどの誤差しか許されず、神経を使いそうです。

そこで、直接会って話せるガラス屋さんを探してみることにしました。電話帳(タウンページ)を繰ってみます(紙の電話帳を使うのはかなり久しぶりです)。「ガラス店」の欄は、ガラスが割れたらすぐに電話を受けたいという業者が、町名をやたらと羅列して何行にもわたって場所をとっていて、ちょうど「水道工事」や「鍵」の欄と似たようなことになっています。こういうところは今回のような特殊な案件を持ち込んでもまったく相手にしてくれないかふっかけられるかのどちらかしかなさそうな気がして、見送りました。ちょっと町工場ふうの業者が割と近くだったので、そこに電話してみました。先に結果を書きますが、これが大当たりでした。

私「そちらは、割れたガラスの修理など個人相手もやってらっしゃいますか? 実は薪ストーブの耐熱ガラスが割れてしまって、それを直したいんですが。」

ガラス店「あー、そういうのはストーブのメーカーに問い合わせられたほうがいいと思いますよ。」

私「実は個人輸入もので、メーカーに連絡をとるのは絶望的なんです。しかも20年ほど前のもので廃番になってるらしくって。」

ガラス店「そりゃあしかたないですね。」

私「それで、耐熱800℃くらいのガラスを切ってもらえたらと思ってお電話しました。」

ガラス店「えっ、800℃! それは無理なんじゃないかなあ。200–300℃のなら扱ったことあるけど。」

私「そうですか。ネットでいろいろ調べてみたら、ネット通販で買えるところはありそうなんですよね。だけど形が長方形じゃなくて、ひとつの辺がまーるくなってて、それを正確に注文するのがややこしそうなんで、近所で直接話せるところがないかなと思ってお電話したんですよ。」

ガラス店「そうなんですか。そのガラスの商品名わかります?」

私「電気硝子建材の『ファイアライト』ってやつみたいです。」

ガラス店「あ、それ扱ってます。そんな高熱でも大丈夫なのか。在庫あるんじゃないかな。」

私「そうですか! 400mm×250mm くらいの大きさです。」

ガラス店「ちょっと在庫調べときますよ。ちなみにネットでいくらくらいでした?」

私「その大きさだと1万円ちょっとになりそうでした。」

ガラス店「うーん。それくらいでできますよ。」

私「ありがとうございます!!」

ガラスにヒビが入ってすぐに電話したのが金曜日の夕方でした。翌土曜日は営業していてしかも外の仕事にも出かけないとのこと。その土曜日に再度電話で確認すると幸運なことに在庫があり、すぐに車で割れたガラスが入ったままのストーブ扉ごと持っていきました。

さっそく作業を始めるガラス屋さん。きれいに2つに割れているだけなので、それをきちんと合わせながら新しいガラスの上に重ねて油性ペンでさーっと線を引き型を取ります。詳しい説明も何も必要ありません。これが対面のいいところ。

雑談しながら作業は進みます。

ガラス店「へえ、扉こんなに重いんですね。薪ストーブはこれまでやったことないもんだから。昨日あれから問屋に聞いてみたりしましたよ。」

私「割れた原因に思い当たることがあって。夏の間に、いったんガラスを外してその回りのガスケット(ガラスロープ)を取り替えたんですよね。そのあと取り付ける時に、この金具のネジをしっかり締めてしまったんですよ。締め付けがきつ過ぎたのが原因だと思います。でもまあたぶん20年ほど一度も交換していないんで、劣化もしてたでしょうけど。」(締め付けすぎが破損原因になるというのが今回検索してみてたくさん出てきました。しょっちゅう扱っているストーブ屋さんならともかく数年に一度(あるいはまったく初めて)しかやらない者だとうっかりしてしまいます。事前にちゃんと調べておくべきでした)

ガラス店「なるほど。確かにちょうどその金具のところから割れてますもんね。」

私「耐熱ガラスを納めることもあるんですね?」

ガラス店「厨房機器や工場の機械の覗き窓なんかですね。それぞれそんな大きくないんだけど、その度にファイアライトを小さいので仕入れていると高くついて。そんな注文が何度かあったんで大きいので仕入れてたんです。それでその端材みたいなのが残ってたんですよ。」

私「なんてラッキーなんだろう。」

ガラス店「はい、できました。はめてみましょう。あれ、ぴったり同じ大きさなのに入らないな。」 (ぴったり入らなかったのは私がつけすぎたボンドがあちこちにはみ出して硬化していたからです。ガラス回りにはボンドは要らないというのも今回検索して知りました。まったく事前に調べておくべきでした。そのはみ出た部分をマイナスドライバーでこそぎ落として、ガラスは無事にはまりました)

ガラス店「今度はネジを締め過ぎないようにね。」

私「はい。」

ガラス店「じゃ、1万円とは言いませんから、8000円で。」

私「ありがとうございます!!」

という具合。面倒な説明も要らず、トラブル発生から24時間以内(実質30分足らず)、8000円(税込)で、ストーブ扉の割れたガラスは完全復旧しました。もし有名メーカーの純正品だったら、たとえばブログ記事のこんなところこんなところ、ストーブ店のこんなところなどを見ると、数万円もかかるところでした。親切な町のガラス屋さんに出会えてほんとうにラッキーでした。

Google Talk は生きている、のか?

先日、ChatSecure という携帯端末向け XMPP クライアントを試してみたとき、Google Talk (Google トーク)をふつうの XMPP として使えることに気がつきました。

2015年の初めころ、Google Finally Kills Off GoogleTalk and XMPP (Jabber) Integration などの記事を見て、XMPP との互換性を捨てて「Google ハングアウト」に移行する形で Google Talk はなくなったものだとばかり思っていました。そう、No, it’s not the end of XMPP for Google Talk というタイトルの記事を読んでいても、です。

これらの記事を目にした前後からついその時に至るまで、自分がふだん使っているクライアント Gajim で Google Talk のアカウントにログインできなくなっていました。それで「ああ、終わったんだな」と思い込んでしまったのです。

ところが先日 ChatSecure を試した際、その ChatSecure では GMail アカウントを用い、まったく他所の XMPP サーバーのアカウントの間でチャットできたのです。

前の記事を今よく読み返してみると、

Note that you can still continue to use the Google Talk Service with a third party XMPP client and the Google Talk XMPP servers continue to federate with other domains.

とあります。

ではどうして、PCのクライアントからはログインできなかったのでしょう? いろいろ検索して調べてみてわかったことは、Google アカウントの「2段階認証」を有効にしていたためにクライアント Gajim からログインできなかったようです。自分もこの2段階認証に切り替えたのが、ちょうど前の記事が出てそれを読んだ頃だったのかもしれません。

アプリ パスワードでログイン」というヘルプがその解決法でした。そこにあるとおりにパスワードを生成し、それを Gajim で使うことで無事にログインできました。いったんログインできてしまえば、あとはまったくふつうの XMPP アカウントとして使うことができます。

時系列的にまとめると

  • Google は 2005年ころ Google Talk というサービスを始めた。それは XMPP の拡張で、サードパーティの XMPP クライアントでも利用でき、また他の XMPP サーバーとも相互に会話できた。
  • Google は 2013年に Google Hangout という、Google Talk 後継のサービスを始めた。この時点で「Google Talk というサービスは終了」と言われているが、Google Hangout の機能のうちの文字によるチャットは Google Talk 互換であり、つまり XMPP として利用できた。
  • 2015年2月、Google 自身による Google Talk アプリ(Windows版)は廃止された。(Android版や、FirefoxやChromeの拡張機能の版も存在していたと思うが、たぶん同じ頃に消えたのだろう)
  • この2015年2月に「Google Talk は死んだ」と言われた。たとえば You Have No Choice: Google To Shutdown GTalk Feb. 23, Hello Hangouts など。しかしその記事でもじっくり読んでみると、However, users who are unable to give up GTalk can use third-party Windows apps, such as the open-source Miranda IM, Jitsi, and Psi, to continue using GTalk. と最後のほうに書いてある。

ということのようです。ただし「安全な接続」については注意が必要です。それこそ前の記事に書いたような、OTR など終端間暗号化(E2EE)を用いるのがいいかもしれません。

ChatSecure — 携帯端末向け XMPP クライアント

ChatSecure という XMPP クライアントの存在を教えられて、手元の Android 端末にインストールしてみました。

インストールは簡単。初期設定はまずアカウントです。Android端末だとたいていは google アカウントが入っているはずで、ChatSecure にもそれを使うかという画面になります。他の XMPP サーバーにアカウントがあってそれを使いたい場合は横にスワイプしてそこで設定します。

ChatSecure の特徴は、このアプリの名前や開発元(The Guadian Project)からわかるように、何と言っても「暗号化」です。OTR (Off-the-Record) という規格にしたがって、終端間暗号化でチャットできます(もちろん相手先もこれに対応していること)。 OTR については、「OTRでオフレコチャット!」の記事などが詳しいです。

「大した内容のチャットじゃなし、暗号化なんて別にどうでもいい」と思うかもしれませんが、巷で流行している LINE のようなサービスと比較して書いてみます。

クライアント-サーバー間が暗号化されているか

これは TLS(SSL) でも実現できます。Wi-Fi 接続やら、インターネット接続プロバイダー、回線会社など途中経路での盗み見・改竄を防げます。

サーバー-サーバー間が暗号化されているか

独立していて他のサーバーとの相互乗り入れができない、ほとんどのメッセージングサービスではあまり関係がないかもしれません。XMPP はサーバー間の相互接続が当たり前ですが、それらのサーバーが適切に設定されていればサーバー-サーバー間も暗号化されています(ちょっと古い記事ですが、Support for STARTTLS and SASL in s2s Connections の図がちょうどいいイメージです)。

サーバー内でも暗号化されているか

TLS でクライアント-サーバー間が暗号化されていても、たいていの場合、サーバー内では復号されて相手先の読めるところに保存されます。サーバー内で何がなされているか、ユーザーは知るすべがありません。サーバーの運営者を信用できるかどうかにかかってきます。発信時に個々のメッセージを暗号化(つまり終端間暗号化 End-to-End Encryption (E2EE))すればここで盗み見・改竄されることを防げます。

端末内の余計な情報を収集していないか

ChatSecureこれは通信の暗号化とは関係ありません。たとえば LINE では、端末内のアドレス帳など余計な情報を収集したりすることがあります。LINE のアプリはソースが公開されていませんので、本当のところ何をしているかはわかりません。独立型チャットサービスでしかもサードパーティのクライアントが許されていないようなものは、運営者をもう単に信じるかどうかという問題です。XMPP や OTR といったオープンな規格、ejabberd のようなオープンソースのサーバー、ChatSecure のようなオープンソースのクライアントという組み合わせでは、そのような信頼できない行為を隠しようがありません。

ChatSecure は OTR を使わなくてもよくできた XMPP クライアントだと思います。見た目は直感的で、操作に戸惑うこともあまりなさそうです。日本語化もされていますし、さほど詳しくないような人にもお勧めできます。

昨年のクリスマスプレゼント「インラインスケート」

また今年もこの時期になったわけですが、昨年のプレゼントを1年間経ってから振り返ってみるシリーズです。

当時6歳のスウちゃん(仮名)の元に届けられたのはインラインスケートでした。秋口に一度アイススケートに連れて行ったらずいぶん楽しかったらしく、何度もせがまれてそのうち2,3回はまた連れて行ったのでした。いっそのことアイスでなくてもいいのでは、とサンタクロース代理人である私は考えました。

当時、まずおもちゃ屋を見てみたのですが、確かに値段の安いおもちゃ風のものはありました。でもちょっとちゃちすぎないか、と思わされる作りでした。いっぽうでネットで調べてみると本格的なものは値段も本格的。そこでそのあいだくらいという感じの「RIP SLIDEジュニアアジャスタブルインラインスケート5点セット イエロー L」にしてみました。これを書いている2015年11月現在、同じものは品切れとなっているようです。

サイズはやや大きかったのですが、靴下を履いてしっかり締めればグラつきはなく大丈夫のようです。滑りはそこそこよかったです。いちばん近くの練習場所は舗装があまり上等ではなく、どちらかというとそちらのほうが問題ですね。いい場所で滑ればかなりいいのだと思います。

アイススケートで少し慣らしていたこともあって、よたよたと歩いては転び立ち上がるというのを数回繰り返した後は、徐々に滑る(というよりは「歩く」か「走る」程度)ことができるようになりました。子どもはすごい。

残念なのは、まわりの友だちも持っていないと楽しく一緒に遊べない、という点ですね。まあちょっと早すぎるかなという年齢でもあるので、同い年の友だちが持っていないのはしかたありません。サイズはアジャスタブルでもう数年は大丈夫なので、そのあいだに仲間が増えるといいな。

『多数決を疑う—社会的選択理論とは何か』を読んだ

多数決を疑う――社会的選択理論とは何か (岩波新書)を読みました。議員選挙などのたびに、多数決よりましな方法があるんじゃなかろうかと漠然と思っていたのですが、それについて追究する学問分野が「社会的選択理論」と呼ばれていることすら知らなかったので、大いに蒙を啓かれることとなりました。

本書の内容は既に公にされている書評(毎日新聞読売新聞など)などにお任せします。検索すればほかにもたくさん見つかります。一方で、きっと本書そのものを読まないままにタイトルだけから「民主主義を否定するのかよ」といった短絡的な批判(?)も見つかります。それほど「民主主義イコール多数決」と思い込んでいる者が多いのでしょう。もちろんそうではありません。意見集約の「方法」についての話なのです。

多数決のもとで有権者は、自分の判断のうちごく一部に過ぎない「どの候補者を一番に支持するか」しか表明できない。(略)だから勝つのは「一番」を最も多く集めた候補者である。(略)

多数決の選挙で勝つためには、どの有権者をも取りこぼさないよう細かく配慮するのは不利というわけだ。とにかく一定数の有権者に一番に支持してもらい、(略)

だがこれは政治家や有権者が悪いのではなく、多数決が悪いのではないだろうか。しかし多数決を採用しているのは人間である。多数決を自明視する固定観念が強い。(本書「はじめに」)

本来であれば社会全体をよくするという政策が出てきてそれが支持されそうなところ、現行の「方法」が多数決であることによって、候補者が勝ちにいくために政策・選挙戦術が歪められ、有権者の行動もまたそれに依存する……。何か本末転倒と思わざるを得ません。

多数決ほど、その機能を疑われないまま社会で使われ、しかも結果が重大な影響を及ぼす仕組みは、他にはなかなかない。とりわ議員や首長や議員を選出する選挙で多数決を使うのは、乱暴というより無謀ではなかろうか。(本書「おわりに」)

多数決の最大の(たぶん唯一の)利点は、「単純でわかりやすい」ということだろうと思います。本書で紹介されるボルダルールやコンドルセ式は集計(開票作業)がどうしても煩雑になります。しかしそれは人間の手作業による場合であって、もし電子投票が実施されるようになればまったく問題はありません。電子投票の問題はたぶん信頼性や投票の秘密の確保とかにあるのでしょうが、いずれその方向にいくでしょう。200年ほども前から提案されている方法に、ようやく技術が追いついてきたと言えます。それに合わせて集約方法も“進化”してもいいのではないでしょうか。

ともかく、多数決よりましな方法が存在します。議員選挙のような簡単には動かしにくい制度よりもっと身近なところ—町内会とかサークルとか学校の生徒会とか—からそういったものが普及していってもらいたいものです。

ボルダルール

さて本書では多数決の代替案がいくつか検討された後、その中でも「ボルダルール」が推されています。その理由として

  1. ペア敗者規準とペア勝者弱規準を満たす
  2. さらに棄権防止性を満たす

が挙げられています。さらに「コンドルセ・ヤングの最尤法は統計学的に定義されるゆえ有権者には理解が難しく、広く受け入れられるとは想像しがたい。であればボルダルールのほうが世に導入しやすいだろう。」と述べています。

しかし、これらについて私は素直に首肯できませんでした。

まず(2)についてです。ここで「棄権防止性」とは、有権者があえて棄権することで結果を自分に有利に変えることができない、という意味で説明され、コンドルセ・ヤングの最尤法ではこれを満たさないとのことです。

ボルダルールでは、候補のすべてに順位を付けて投票しなければなりません。ではたとえば最近の都知事選挙を考えてみます。これだけ候補が多いと、大部分の有権者は、もっとも好ましい候補からせいぜい3人ほどと、この人には絶対なってほしくないという候補の2,3人ほどが頭に浮かぶ程度ではないでしょうか。何がなんでもすべての候補を一列に並べなければならない、とすると有権者への負担はとても大きくなり、そんなことならいっそ棄権してしまおうかという気持ちにもなってしまいそうです。棄権で結果を自分の有利にできないから棄権する動機がないという意味の「棄権防止性」はあるのかもしれませんが、「めんどくささ」からの棄権を多く誘発しそうです。もしすべての候補にではなくて「いくつかだけに順位をつければよい」というルールにすると、それはボルダではない「スコアリングルール」になってしまい、(1)を満たさなくなってしまいます。この「めんどくささ」、つまり有権者の高負担というボルダルールの不利な点をどのように克服できるのか、そこまで本書で説明されていればよかったのにと思いました。

シュルツ方式

本書には出てきませんがコンドルセの一種として「シュルツ方式」というものがあります[1]

Wikipedia のページをざっと読んでみたところ、シュルツ方式の投票は、ボルダルールのように候補に順位を付けますが、

  • 複数の候補者に同じ番号を付けてもよい
  • 連続しない番号をつけてもよい。番号の絶対値は重要ではなく、順序のみに着目する
  • いくつかの候補に順位を付けなくてもよい。その場合、順位付けしていない候補を最下位(順位付けしていない候補どうしは同列)とみなす

というものです。コンドルセ式のためペア勝者規準をも満たすようですし、また全部の候補を順位付けせずに部分だけでもよい、とありますから、上に挙げた私のボルダルールに対する疑念も克服されているようです。簡単な比較の日本語記事が『「多数決」以上に民意を反映できる選挙方法とはどのようなものなのか?』にありました(本書の出版より前の記事です)。

Debian Project採決にこの方式を採用しているということを、実は以前から知っていました。しかしこれが多数決などとどのような関係にあるか、考えたことはなかったのです。今回、『多数決を疑う』を読み、あらためて見てみました。英語ですが The Debian Voting System は、Debian での方法に限らず一般的なコンドルセやシュルツの説明としてわかりやすいです。

そこにあるように、Debian 方式は

  • 選択肢に「更に議論する」を追加する
  • デフォルトはこの「更に議論する」とする

という拡張がなされています。一般の投票なら「他に選択肢がない」や「どちらともいえない」などを読み替えることができるでしょう。つまりデフォルト選択肢より上の順位にすれば「好ましい」、下の順位は「好ましくない。嫌だ」という意思表示になります。これはたいへん合理的なルールだと思えます。

この拡張の優れた点は、ただの賛否を問う採決でも(選択肢が「賛成」「反対」の2つしかなければボルダルールも何もただの多数決になってしまう)、選択肢が「賛成」「反対」「更に議論する」の3つになり、コンドルセ式などを適用できることです。もっともこれを「迅速に決定できない」という欠点だとみなすこともできますが、私は、拙速よりははるかにましだと考えます。

多数決を疑う――社会的選択理論とは何か (岩波新書)……と、実は本書を読んだのは数か月前なのですが、何しろ専門でも何でもないので、調べたり考えたりしながらこの辺まで書くのにうんと手間取ってしまいました。このままではいつまでたっても書き上がらないので、ひどく中途半端ですがもうここでこの記事を公開してしまうことにします。

ついでに、私の抱いているもうひとつの疑問も書いておきます。

私の住む市の今年春の市議会議員選挙では、立候補者数は定数をわずかに超えるだけでした。つまり30人ほどが当選し、ほんの3,4人しか落選しません。最適の候補をたったひとつ選ぶ場合にはコンドルセ式やボルダルールが使えそうですが、このような場合にも適用できるのでしょうか。本書からだけではよくわかりませんでした。たとえば「投票方式はこれで決まり?」で言及されている方法などは有用そうなのですが、それと他の方式との比較などが自力ではよくわからない……。

様々なケースにも適用できるベストな方法はどうやらなさそうだ、という感じはうすうすしているのですが、それでも本書で言うように「コンドルセ式よりもボルダルールが優れている」とは思えませんでした。さらにもっと別の方式も同じ土俵に上げて、上述した疑問にも私のような素人にもわかりやすく答えてくれる、続編に相当するものが現れないかなと思っているところです。

  1. WikiPediaの解説はとても参考になりますが日本語版の「シュルツ方式」は翻訳が変なところも多い(2015年9月現在。そう思っているなら直せよと言われそうですが、時間があれば少しづつそうしていきたいと思います。しかし私のような素人よりもっと専門知識のある人たちにやってほしい……)ので、それを参照しながら英語版 Schulze method を見たほうがよさそうです。

先取りなのか回り道なのか—さんすう編—

長いあいだこのブログも更新していなかったが、そうするうちにスウちゃん(仮名)は1年生になった。

8か月ほど前に「ドミノとさんすう」で、その頃の“さんすうのおべんきょう”について書いてみたのだが、現在の状況についてメモしておこう。なお家での独自の“べんきょう”についてであって、学校でのさんすうや宿題は、これとはまた別にあるのは言うまでもない。

前の記事の『ふたたび「さんすう」』の節にも書いたとおり、筆算(縦書き)をかなり早めに(ほとんど意味がないと思える1桁どうしの計算のころから)教えてきた。また、ブロックを使っていたものが2桁どうしになるとほぼ無理となり、簡単な図を描くように変わってきた。

現在(小学校1年生の6月末)は、2桁どうし[1]のたし算・ひき算の筆算を、脇に図を書きながらやっている。とにかくたし算・ひき算だ。かけ算は1桁どうしもやっていなければ、図形もやっていない。

こちらが問題を考えて作ってやるのが面倒なので、半自動で作成するようにした。つまり、LaTeX の emath マクロを利用して、その中の

を使って、A4横置きの紙に20問(たし算かひき算かはランダム)を出力するようにした。スウちゃんは気が向いたら(それは退屈でほかにやることがないときか)これをプリントして、やっている。

繰り上がりや繰り下がりのときの「筆算でのテクニック」—上に1を書くだの—は教えていない[2]。そのため、脇に図を描いては「10の束が何本、ばらが何個」というふうにやっている。わりと間違えないし、そこそこ速くできるものだ。

「テクニック」はそのうち学校で教わるだろう。そのときにあっと思ってくれればいい。テクニックばかり先に覚えてしまうとその元になっている考え方は忘れてしまうだろう。そういえばいま学校では1桁のたし算(結果が10まで)をやっている。宿題で「けいさんカード3回」などが出る。単語カードのようなものの表側に「2+5」「3+1」「4+4」と書かれていて(たとえばこんなようなもの)、それをすばやくめくりながら「なな!」「よん!」「はち!」と声を出すのだ。たし算のしくみはきっちり教えられたうえで、いまはこのカードなのだと思いたい。

筆算の「テクニック」は学校で教わるころまで措いておくことにして(そのうち自分で“発見”するかもしれないしね)、今日もまた棒と丸の図を描いているのであった。

  1. 計算の結果が3桁になることもある。
  2. ただし繰り上がり(「10束が1本できるよね」)や繰り下がり(15-7など)そのものの考え方については教え、何度もブロックで手を動かしてきた。

Debian 8 の Mailman 2.1.18 に更新したらトラブルが起きた

メーリングリスト(ML)を運用しているサーバー の OS を Debian 7 (Wheezy) から Debian 8 (Jessie) に更新しました。これにより、ML 管理ソフト Mailman のバージョンが 2.1.15 から 2.1.18 になりました。

すると ML の配信に失敗する(ML に宛ててメールを出してもどこにも配信されない。エラーも返ってこない)状態になってしまいました。OS のバージョンアップだったので、関係するソフトウェアの多くが更新されており(たとえば Bind9, Postfix, Python,…)、しばらくどこが原因かわからず途方に暮れていましたが、ようやくエラーログを見つけ出し、それを検索して調べることで解決できました。

結局のところ、この人と同じで、MLの説明などを日本語(EUC-JP)で記述していた箇所を Web の管理画面から書き直すことで、何のことはなく問題は解消しました。

こういうのはだいたい解決してしまった後に見つけるものですが、/usr/share/doc/mailman/NEWS.Debian.gz に、

mailman (1:2.1.16-1exp1) experimental; urgency=low

  This version has changed the encoding of most strings, templates
  and pages to UTF-8 to meet the Debian release goal of full UTF-8
  support in all packages. It also no longer automatically converts
  mails to ISO-8859-1.

  If you have been using any nōn-ASCII strings in places such as
  the mailing list description, these were be stored wrongly in the
  list configuration file (config.pck), so you will need to change
  those (e.g. via the webinterface) again in order to have them be
  displayed correctly.

と書いてありました。

さてメールは配信されるようになったものの、ヘッダーに DKIM-Signature: が残っていて、設定ファイル /etc/mailman/mm_cfg.py に記述していた REMOVE_DKIM_HEADERS が効いていないようです。以前はちゃんと機能していました。

これまた検索してみると、オプション from_is_list と組み合わせないと効かないようで、それと無関係に効かせようとしてもバグがあるようです。上流の新しい版では修正されているので、Mailman/Handlers/CleanseDKIM.py を差し替えました。

その上で、設定ファイルで REMOVE_DKIM_HEADERS = 2 としました。