テキストベース電子メールクライアントへの回帰計画
テスト候補を絞る段階では、なるべく多数を網羅すると同時に、現在もメンテナンスが継続中で、入手ないし運用時に過度の負担を必要としないソフトウェアのみを選ぶようにした。より具体的に言うと、依存関係が特異的であったり、コンパイル時の諸設定が煩雑すぎるメールユーザエージェント（MUA）は今回の候補から除外してある。例えばElmoは評価の対象外としたが、その理由を述べると、2004年以降にアップデートがされていないこと、ホームページが最近更新された形跡がないこと、Elmoの開発者に今後の計画を電子メールで問い合わせても返事がもらえなかったこと、となる。往年のElmoには期待させられる点が多かっただけに、これは残念な事態であった。またElmについても、その開発状況は不透明だと判断した。実際、私が常用している全てのディストリビューションに関して対応パッケージが見つからず、また込み入った設定スクリプトが複雑すぎて、フラストレーションの元となりそうだったからだ。
Pine
最初にテストするのはPineにしたが、それは以前に使用経験があったため、現在どのレベルにまで発展したかを確認してみたかったためである。Pineは、University of WashingtonのComputing & Communicationsによって1989年に作成されたアプリケーションである。
Pineには、固有エディタのPicoおよび、ファイルシステムブラウザのPilotが付属している。PicoとPilotはスタンドアローン型のアプリケーションであり、必要であればPineを起動しなくても使用することができる。
テキストベースの電子メールアプリケーション群の中でも、Pineの操作性は頭抜けて優れている。いずれの操作画面も分かりやすいメニュー構成を取っており、ユーザが必要とするであろう機能に簡単にアクセスできるよう配慮されているのだ。Pineの設定はメニュー経由で行える。その構成には改善の余地があるとは思うが、Pineの設定オプションを一覧できる点は便利だと言えるだろう。他のテキストベースのメーラの場合だと、用意されている設定オプションの種類を確認するだけでもmanページやオンラインマニュアルを探し回る必要があり、必要な変更を施すには別途テキストエディタを起動して設定ファイルを編集するといったケースが多い。
とは言うものの、Pineの設定作業すべてが他のメーラより簡単という訳ではない。Pineの用途として適しているのはメッセージを送信するシステム上で使用する場合だが、そのためのSMTP設定にはかなり複雑な手順を経る必要があるのだ。
なおPineでの暗号化設定も一筋縄では行かないが、GnuPGをPineで使用するための解説やアドオンの紹介ページが存在している。
なおPineは“フリー”なライセンスで公開されておらず、現在多くのLinuxディストリビューションはPineパッケージの同梱を取りやめている。とは言うものの、Pineをソースからコンパイルする作業はそれ程複雑でもなく、またライセンスのフリー度についても、パッチやセキュリティアップデートの責任を負うベンダやプロジェクトは神経質に成らざるを得ないかもしれないが、一般ユーザの多くにとっては充分に許容できる範囲内だろう。
Pineをベースとした派生ソフトとして、Alpineという現在開発中のメーラが存在する。ただし現行のアルファ版を入手したければ、Alpine-alphaメーリングリストに参加するしかない。私の知る限り、開発陣によるAlpine関連の情報はこのメーリングリストに上げられているだけであり、アーカイブすらも購読者のみ利用可という態勢だ。今回は11月29日に公開されたファーストリリース版を試用しようと思ったのだが、UbuntuおよびDebian環境でのコンパイルはできなかった。
Alpineに関する朗報として、このアプリケーションはApacheライセンスのバージョン2.0でリリースされている点を紹介しておこう。もっとも、そうした措置ができるのなら、Alpineが完成するまではPineについてもApacheライセンスでリリースするようにしておけば良さそうなものだが、何らかの理由があって開発元の大学がそのようなオプションを選んでいないのかは不明である。Pineの愛用者たちにとっても、Apacheライセンス下で公開されたバージョンがDebian、Ubuntu、Fedoraその他各種のディストリビューションに同梱されるようになれば、Alpineの安定化まで待たされる必要もなく、願ったりかなったりだと思うのだが。
Cone
Console Newsreader and Emailer（Cone）も、Pineと似ているテキストベースの電子メールクライアントの1つだ。ただし似ていると言っても、それはメニューの構成およびキーバインディングに関しての話で、その他の相違点はPineに慣れたユーザをイラつかせるのに充分であろう。ConeはテキストエディタとしてLeafを使用するが、こちらはPicoないしNanoに似ている。
Coneの機能は、テキストベースのメーラとしては非常に充実している。IMAPへの対応、組み込み式の署名および暗号化機能、マルチアカウントのサポート、メールの自動保存機能、タグ処理を始め、メーラを利用するためのチュートリアル群も用意されている。
ただしConeにおけるSSLの対応状況は完全なものとは言えない。例えば、ConeでSSLを用いたIMAP接続を行おうとすると、ルートの認証権限が無いために暗号化接続ができないという旨のメッセージが表示され、接続処理を中断するか、あるいはサーバ名に”/novalidate-cert”を追加して無認証でサーバを使用するかのオプションが提示されるのだ。こうしたエラーメッセージを表示するのであれば、ルート権限による認証に必要な設定法をユーザに説明するようにすべきだと思うのだが、どうだろう。
Coneも、大部分のLinuxディストリビューションには同梱されていないので、使おうと思えばソースからコンパイルする必要がある。もっともPineの場合とは異なり、Coneが用いているGPLライセンスならばフリーな配布ができない訳ではないのだが、いかんせんメーラとしての知名度が低すぎてDebianやUbuntuなどのディストリビューションには同梱されていない、というのが実状だろう。
Mutt
*BSD系およびLinuxディストリビューション用のテキストベース型MUAで最も人気のあるのは、今ならMuttだということになるだろう。その人気の高さには無視し得ぬものがある。ライセンスについてはGPLが用いられているので、Pineのような制限は存在しない。また機能面に関しても、IMAPおよびPOP3への対応、各種メールボックスフォーマットのサポート、メールヘッダに対する制御機能、PGPおよびMIMEのサポートなど、非常に充実している。
テキストベース型メーラとしてのMuttは、実務に適した高度な柔軟性も有している。Muttのキーバインディングは.muttrcという設定ファイル上で変更できるが、マクロを組めば特定操作のキーストロークを自動化したり（メッセージの保存やフォルダの切り換えなど）、Bogofilterなどの外部プログラムにメッセージを転送させることも可能だ。
Pineと同様、Muttでも使用頻度の高いオプションの多くはメニュー上に一覧されるようになっている。ただしMuttの場合、各画面上に表示されるオプションは一部に限られており、残りのコンテキストオプションを見るには?を押さなければならない。この画面では多数のオプションが無秩序に一覧されるだけなので、初心者にとって非常に分かりづらいのが難点だ。ただしMuttで設定可能なオプション数はPineよりも多いので、その点は実際に使用する場合における1つのメリットと評価すべきだろう。
次に、PineやConeと比較した場合の欠点だが、Muttには専用の設定ユーティリティが付属していないのだ。つまり、IMAPアカウントの設定、あるいは送信メールにおけるFromヘッダの表示変更といった作業は、すべて.muttrcファイルを直接開いて必要な変更を施すしかない。こうした仕様はMuttの初心者ユーザにとっては苦痛の種となるだろうが、実際に長期間にわたって使用し続けるという観点から見た場合、多くのカスタマイズが施せるという特長は生産性を高める要素となるはずだ。
nmhおよびMH-E
nmhとはNew Mail Handling Systemの略称であり、そのメール管理方式は他とは異なる非常に特徴的な手法が採用されている。この特徴的というのは、Muttなどの標準的なMUAであれば、プログラムの起動、メールの閲覧や送信、あるいはメッセージの保存といった各種の操作は、すべて単一のインタフェースを用いて操作するようになっている、という意味での話である。
それに対してNmhの場合は、個々のタスクごとに異なるプログラムを使い分けるという構成になっている。つまりnmhというコマンドを実行すれば、よくある電子メールの管理インタフェースが表示される訳ではないのだ。Nmhとはコマンドの集合体であって、特定のメッセージを表示させたいならshow、次のメッセージに移動するならnext、前のメッセージに移動するならprev、新規メッセージを作成するならcompをそれぞれ実行するといった仕様になっているのである。Nmhでのメール管理において、ユーザは30以上のコマンド群を使い分けることになる。
例えばnmhで受信メールの閲覧作業をしようとすれば、まずincによってメールスプールからメールフォルダに電子メールのデータを取り込み、次にshowによってメールを表示させてから、prevで前のメッセージを読み込み、最後にreplによってメッセージへの返信を行うといった手順を踏むことになる。こうした操作はいずれも通常のシェルコマンドとして行うのであって、独立した電子メールプログラム上で実行する訳ではない。
Nmhの場合、ローカルスプールからの電子メール取得という操作はユーザが別途行うことを前提としているので、リモート環境でのメール閲覧をする場合は、ローカルシステムへのメール取得に用いるFetchmailやGetmailなどのツールが必要となる。
電子メールクライアントという範疇で言うならば、nmhの使用はお勧めできない。その操作性は直感的とは言い難く、原型となったMessage Handlingユーティリティ群の使用経験のあるユーザ以外は誰も使いたいとすら思わないだろう。ただし、他のMUAを介したMHメールボックスへのアクセスを行っているユーザであれば、メッセージ制御用スクリプトに流用できるものがnmhのユーティリティ群の中にあるかも知れない。
EmacsユーザであればMH-Eを試してみるのもいいだろう。MH-Eとは、EmacsからMHにアクセスするためのインタフェースであり、ある程度の簡便なMHシステムの操作を行うことができる。ここで“ある程度”という表現を使ったのは、私の短い使用経験内で見る限り、MH-Eの操作性はnmhユーティリティ群による直接的なコマンド操作と同程度のものでしかないからだ。
これらの各種MUAを試用してみた結果、最終的に私が選んだのはMuttであった。これは、Mutt側でMHスタイルのメールボックスを扱うよう設定しておき、MuttとSylpheedとでメールフォルダ群を共有させておけば、Muttをメインに使用しつつGUI式メーラも補助的に利用できる体制を組めるという判断からである。
