テキストベース電子メールクライアントへの回帰計画：Leverage OSS（2/2 ページ）

[Joe-'Zonker'-Brockmeier，Open Tech Press]

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式メーラーも補助的に利用できる体制を組めるという判断からである。

原文へのリンク