squirrelmailからrainloopへ乗り換えてみた

前置きです。

CentOS5ではimapクライアント用にsquirrelmailを利用させていただいてました。
かなり高機能で日本語対応も割合しっかりしていたし、カレンダープラグインもついていたので簡易グループウェア的な使い方も出来たので、かなり改造しまくって便利に利用させていただいていました。

しかし、悲しいかなphp4用なのでCentOS7では改修するかphp4をインストールしないと使えません。
ですが、php4を入れるのはまっぴらごめんですし、php5向けのﾊﾞｰｼﾞｮﾝもリリースされてはいるのですが、これがまたなんとしたことか、日本語のメールの文字化けがひどい。

これを改修して、さらに以前のsquirrelmailの改造を反映させるとなると、ちょっと導入をためらいます。

それに、実際には東日本大震災の時の計画停電のため、まともにMXレコードの宛先としては運用できなくなってしまい、それ以来MXだけは宛先をgoogleに委託してしまったので、グループウェアとしての機能も不要になっていました。

加えて、euc-jpであるというのもネックです。

utf8にしておけば今後どんなヘボいﾌﾞﾗｳｻﾞが主流になったとしても切り捨てられることはまずありませんでしょうが、日本国内ではｲﾝﾀｰﾈｯﾄ上で日本語といえばこれだ!!っていう位置を占めていたはずのISO規格のISO-2022-JP(要するにJISコード)も過去にIEにばっさり切り捨てられた実績があります。
したがって、ISO-2022-JP以上にマイナーな文字ｺｰﾄﾞは避けたい。

現在は取引結果などの残しておきたい古いﾒｰﾙやroot宛てのﾒｰﾙなどが確認できればいいので、これを機に長年お世話になったsquirrelmailさんから卒業させていただき、新しいWebメールシステムを探すことにしました（いつgoogleさんがGoogle Appsを放り出すかわかりませんから)。

すると、同じくphpのRainLoopというWebメールシステムを知りました。

ｽﾊﾞﾗｼｲ。実にｽﾊﾞﾗｼｲ。

zipファイルをダウンロードして、展開して、展開したディレクトリをapacheなどで公開するだけでインストール終了。
設定は、初期管理者id/パスワードがadmin/12345と定義されていて、これを用いてブラウザ上から設定するので、管理者idとパスワードを変更するまではHTTPサーバの起動前にallow先をlocalhostに限定するなどしたほうがいいと思います。

そのうえ動作も軽快、デザインもきれい。日本語も化けない・・・規格内のメールなら(*今日の本題。後述します)。

面白いのは、オンラインデモが用意されていて、どういうものなのかインストールせずに実際に触って試せるところ。
あと、FacebookとGoogleとTwitterとDropboxと統合できるんですけど、ソーシャルとか大嫌いだからやらない。やらないけど、興味がある人のほうが多いはずだからこれも一大特徴といっていいと思います。

大いに気に入ったので採用です。
コミュニティエディションはAGPLv3ですが、別ライセンスも用意されていて、商用利用にも配慮されているようです。

さて本題です。

先ほど日本語も化けないと書きましたが、これはウソではありません。

が、あくまで規格に則ったメールが化けません。
これは規格に則った正しい動作です。文句のつけようがありません。

しかし、日本って割と古い時代からｲﾝﾀｰﾈｯﾄが普及した国の一つ、かつ、漢字というアルファベットじゃ表せない文字を初期から持ち込んだりしたので、混迷状態にありました。
EBCDIC系のCCSIDとかJUNETコード(のちのISO-2022-JPとかJISとか呼ばれるｺｰﾄﾞの元祖)とかEUC-JPとかSJISとか経路上で最上位ビットが落ちるとか落ちないとか。
技術者の工夫の歴史でもありますが、まあ、今となっては迷走と言われてもしゃあないかなあ。

折角規格ができても誰も実装しないとかザラで、挙句に自分の使っているOSの文字コードで直接メールを送受信してしまうという快挙暴挙にでるﾒｰﾙクライアントがごく普通に使われちゃったりしちゃったりして(最近でもまだ見かけます。問答無用でUTF8とかね)。

で、当時はインターネットといえばJISコードを使え、ということになっていて、そいつを直接MIMEエンコードせずにSubjectやFrom,To欄に使ったりしてるメールが多かったりします。
MIMEが普及し始めたのって記憶では90年代くらいで(なぜかってーとその頃その手のプログラムの改修を受注して書いた覚えがあるから)、その間も直接mailコマンドでドドーンとMIME?ナニソレ?なメールが行き交っていたり。

で、そういうメールでは当然お作法が守られていません。
ヘッダにJISコードが直打ちなのはともかく、そもそもContent-Typeが定義されてない、されててもcharsetが定義されてないとかザラです。それでも日本国内で主に使われているﾒｰﾙクライアントの場合はほぼ間違いなく正しく表示してくれますので顕在化しにくいですが、それはバッドノウハウの賜物です。

で、今回利用させていただくことにしたRainLoopさんでは、こういった不届きものはもれなく化けます。
仕様を守っていませんし、仕方ないですね。

・・・というわけにはまいりませんので、ちょこっと修正します。
現在のコミュニティエディション ver 1.9.3.365を例に修正例をご紹介します。

まずヘッダです。
rainloop/v/1.9.3.365/app/libraries/MailSo/Mime/HeaderCollection.php： 272行目(Parse関数内)に下記を追記します。

if( stripos( $sRawHeaders, "Content-Type" ) == false ){
        if( strpos( $sRawHeaders, 033 ) != 0 ){
                $sRawHeaders = "Content-Type: text/plain; charset=\"ISO-2022-JP\"\r\n" .
 $sRawHeaders;
        }
}

これはContent-Typeがないメールでヘッダ内にESCコードがある奴はISO-2022-JPと決めうちしてしまうものです。乱暴ですねぇ。mb_detect_encodingを使用しないのは、ある程度実験したところ、まるで使い物にならなかったからです。直撃したほうがまだマシな程度に使い物になりませんでした。
いろんな国がありいろんな言語がありますから、本当に大変なんだろうなぁ、としみじみ思いました。

お次にボディです(ボデーといまだに言ってしまうので格好つけてみました)

rainloop/v/1.9.3.365/app/libraries/MailSo/Mail/Messages.php: 783行目(InitByFetchResponse関数内)に下記を追加します。
if( $sTextCharset != "iso-2022-jp" && strchr( $sText, 033 ) !== false ){
   $sTextCharset="iso-2022-jp";
   $sText = mb_convert_encoding( $sText, "utf8", "iso-2022-jp" );
}

これは、iso-2022-jpなcharsetじゃないのになんで本文がエスケープされてんだよオイ、という時に無理やりJISからUTF8に変換してしまう、まことに乱暴なｺｰﾄﾞです。

これで、前世紀から今世紀初頭のメールもめでたく現代においても読めるようになりました。

こんな記事、誰が必要とするのかわかりませんが。

どうでもいいですが、このrainloopのソースはきれいで読みやすかったです。
phpで書かれたｺｰﾄﾞに対して私がこんなことを感じるのは、これは大した褒め言葉ですとも。