Archive for 8月 2009

majordomo におけるフッタ追加機能

運用の管理を担当しているメーリングリストで、このところ文字化けの問い合わせが増えてきた。調べてみたところ majordomo がメール本文に追加するフッタ文字列が原因らしい。majordomo は本文のエンコード状況に関わらず、そのままプレーンテキストのフッタを追加しているようだ。そのため本文がプレーンテキストでない場合、本文中には複数のエンコーディングが混在してしまうが、マルチパート用にメールヘッダを書き直すことはしない。そして結果的に受け取り側メールクライアントによっては、正しく表示できない状況が発生する。

ここのメーリングリストには、ほとんどプレーンテキストしか流れていなかったので、これまでは問題にならなかった。しかし、プレーンテキストにも関わらずエンコードされたメールが、最近発信されるようになったため不具合が顕在化してきた。ちなみに問題のメールのヘッダはこんな感じになっている。

Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: base64

このようなデータであっても、大抵のメールクライアントはエンコード部分をデコードしてくれて、なんの問題も無く読めてしまう。もっとも majordomo が追加したフッタの表示はおかしくなっていたり、まったく表示されなかったりするのだが、本文が読めているため気付きにくくなっている。ところが Gmail でこのメールを表示させると、肝心の本文部分のデコードは行われずにエンコードされたままのテキストが表示される。不具合の問い合わせをしてきた利用者も Gmail を使っていた。

結局、これまでフッタに追加していた情報は、それほど重要なものではなかったので、majordomo におけるフッタ追加の機能を無効にすることで、この不具合を回避することにした。

ところで、そもそもこの不具合に気付いたのは、単純なプレーンテキストがわざわざエンコードされてきたからだった。実はこれにも Gmail が絡んでいた。Gmail に限らずいわゆる Web メールの GUI でメール本文を入力するとき、利用者が改行を入力するまでいくらでも長い文字列を1行として入力できてしまう。このような本文を書いて送信すると、Gmail はどうも自動的に base64 でエンコードするようだ。この仕様はたぶん間違っていないと思う。ちなみに文字コードに utf-8 を指定している場合は、行の長さに関係なく無条件にエンコードされるようだ。

これからはどう考えてもエンコードされたマルチパートで構成されるメールが増えてくるだろうから、majordomo では対応しきれなくなってくるだろう。今回のようにメーリングリストの中継点でメール本文にヘッダやフッタを追加するには、送られてきたメール本文のエンコード状況を解析し、マルチパート化するような処理をしなければいけないのだと思う。最近はあまりメーリングリストに関する技術情報が出回っていないような気がするが、Mailman だったらこんな要求に対しても対応できるのだろうか。この際だからいっそのこと Google Groups のような既存の無料メーリングリスト・サービスなどに身を委ねてしまえば楽になれるのかもしれない。