フリーな IMAP Server の選び方

現在、フリーのIMAPサーバの実装としては、

• ワシントン大学の IMAPd ( UW IMAP)
• CMU の Project Cyrus の imapd (Cyrus imap)
• Courier IMAP
• Dovecot

あたりが有名なところです。 この文書では、この上記の実装を比較・検討します。 IMAPサーバの選択の助けになれば幸いです。

機能比較

考慮ポイント

保存形式

まず、ポイントとして、従来から使われている形式を使うか、Cyrusのように独自形式を使うか、ということを考慮する必要があります。 mbox や Maildir のような従来形式を使う理由としては、

• サーバにログインして直接メッセージを読むことができる
• procmail などのメッセージを取り扱うツールが対応している

などが考えられます。

しかし、Maildir対応のように、形式的には従来形式ですが、 特殊な使用方法をしている場合もありますので、 IMAPサーバと使用するツールのドキュメントを読んで、 問題がないかどうか確認する方が良いでしょう。 また、IMAP以外で勝手に操作したためのキャッシュの不整合が発生する可能性も考慮しましょう。

次に、大きく分けて形式が、mboxのような1フォルダー=1ファイル形式と、 Maildirのような 1メッセージ=１ファイル形式があります。 一般的に言って、1フォルダー＝1ファイル形式ですと、 フォルダーが大きくなったときにメッセージの操作が非常に遅くなる可能性がありますので、 メッセージを大量に操作する場合には注意する必要があります。 ランダムアクセスについては、 別途インデックスファイルを用意するなどしてパフォーマンスを向上させている場合もありますが、 削除などの場合にはファイルをまるごとコピーする必要から、 速度が期待できない場合もあります。 また、1メッセージ＝1ファイル形式ですと、 今度は大量のメッセージがあると、一覧表示などが、非常に遅くなる可能性があります。 この問題は、使用するファイルシステムとして、 ディレクトリのスキャンが早いもの (Linux の ReiserFS や FreeBSDでの DIRHASHオプションなど) を選択すれば緩和される可能性があります。

CHARSET

IMAP4rev1 ではサーバ側でメッセージの検索を行うことができます。 クライアントからヘッダや本文などの位置の指定と、 検索キーワードをサーバに渡して検索を依頼します。 この時、キーワードにはその文字列のCHARSET (iso-2022-jpなど)も指定可能です。

今回取り上げた実装は全て、 検索キーワードもメッセージ自体も両方ともUTF-8に変換した後、比較を行っています (このあたりの振舞いは IMAP4rev1 では規定されていないため、 他のサーバ実装では異なる場合もあり得ます)。

つまり、サーバに保存されているメッセージの CHARSET と、 クライアントが検索時に指定する CHARSET の両方をサーバがサポートしていないと、 検索が失敗してしまいます。

多くの場合、検索対象は 欧文(us-ascii, iso-8859-*) と 日本語 (iso-2022-jp) で、クライアント側は iso-2022-jp を指定して検索するようですので、 これらがサーバでサポートされていれば、検索は成功することになります。 しかし、その他の要件がある場合には、注意する必要があります。

個人の名前空間

サーバとクライアントの問題として、名前空間(NAMESPACE)の違いがあります。

IMAPではサーバ上にフォルダーが置けるわけですが、 名前空間とは、このフォルダーの配置方法のことです。 例えば、個人のフォルダーはどこに置けて、共有フォルダーはどこに置かれて、 階層区切りの記号は何が使えるか、といったことです。

このあたりの名前空間の規定は IMAP4rev1にはなく、 サーバによって様々です。 これではクライアントがどう振舞えばいいのかわからなくなります (例えば、ゴミ箱(Trash)フォルダーをどこに作ればいいのか？)。

これを解決するために、

• クライアントの設定で名前空間を指定できるようにする
• クライアントが NAMESPACEコマンド(rfc2342)によってサーバから情報を取得する

という方法が多くの場合とられています。

しかし、クライアントによっては、 名前空間が決め打ちだったり、 特殊な名前空間に対応できなかったりという場合があるので、 そのようなクライアントを使用しなければならない場合、 クライアントが想定している名前空間を使える実装を選択する必要があるかも知れません。 そのような場合の多くは、初期から使用されることの多かった、UWの INBOXと同じ階層に個人のフォルダーを置く名前空間を想定している場合が多いようです。

因みに、受信箱(Inbox)の下に個人用のメールボックスを置く実装を使った場合、 クライアント側の表示が心理的に気持ち悪いという意見を聞くこともありますが、 これはサーバの問題というよりも、クライアントの問題です。 クライアントは何もサーバが返す階層構造のまま表示する必要はなく、 個人用のメールボックスを Inbox と同レベルで表示しても構わず、 実際、そのような実装はあります。

認証

POP3にAPOPという、平文パスワードがネットワークを流れない機能がありますが、 同様な認証方法が SASLという枠組の中で IMAP でも用意されています。

SASLには様々な認証方法がありますが、 全てをサーバもクライアントもサポートしているわけではないので、 使用するクライアントがサポートする認証方法をサーバがサポートしているかどうかを確認しておく必要があります。 多くの実装が CRAM-MD5をサポートしていますが、そうでない場合もあります。

機能一覧

(2007/5/1現在)

尚、別パッケージ、パッチなどで機能追加されるものもありますが、 ここでは標準パッケージでの機能を紹介しておきます。

雑感

UW

とにかくサポートする保存形式が多彩なため、 現在使用しているメールサーバを簡単にIMAP4に対応させるには良い選択です。 ただし、Maildirには正式には対応していませんし、 作者も対応する予定はありません。

しかしながら、普通、その場合に使われてる mbox やmh 形式では、 大規模なサーバには耐えられないため、 メール保存形式の変更などのチューニングを行う必要がありますので、 その場合には容易さの利点が無くなってしまいます。

Cyrus

IMAP4専用に設計されているため、IMAP4的機能の豊富さと、 パフォーマンスの良さが利点です。 数万ユーザを超える大規模な環境での動作実績があります。

しかしながら、完全に独自形式のため、 メールサーバの移行には多少の苦労が必要です。

Courier

Maildirに対応していることと、 機能をモジュール的に切り離せるため、 サーバを軽くすることができることが利点といえるでしょう。

また、Courier-MTA という、 MTAなどを含むパッケージの IMAP 部分ともとらえることができます。 そう考えると、他の実装のように、 外部のMTAとの組み合わせるときの設定で悩むことが少ないかもしれません。

Dovecot

長らく待たされましたが、ようやく1.0がリリースされました。 後発だけあって、他との互換性が考えられているところや、 比較的軽いという理由で、 小規模環境で導入されることが増えているようです。

パフォーマンス比較

To Be Continued...