簡単セットアップ ---------------- もし mbox を使うのでしたら、他のシステムと同じように mbox_locks の設定が行わ れていることを確認してください。 client_workarounds をチェックして、必要であれば有効にしてください。 もし新しい SSL 証明書の作成が必要でしたら、 dovecot-openssl.cnf を編集して、 mkcert.sh を実行してください。 dovecot-example.conf を使って設定をすることは良い考えです。そのファイルは、 良いコメントが付されています。 認証 ---- auth.txt を参照してください。 maildir か mbox か? -------------------- Maildir 形式ではそれぞれのメッセージを別々のファイルに保存し、メッセージフラ グは info というファイル名で保存します。どちらにしても、それはとても壊れそう にない maildir を作成します。 maildir から多くのメールを読むことは、 mbox よりも遅く、それはそれぞれのメー ルファイルを別々にオープンする必要があるためです。しかし、メールボックスの更 新は、 mbox よりも非常に早いです。 とても大きなメールボックスでは、例えば、 ReiserFS や XFS や JFS のような、 ディレクトリに b-tree やハッシュインデックスを使うファイルシステムを使うこ とは、とても良い考えです。ext2 と ext3 はこれを実行するためのパッチがありま すが、それは Linux 2.4.20 には含まれていません。 *BSD のファイルシステムにつ いては確かではないですが、 FreeBSD の ufs はいくつかのハッシュのサポートをし ています。 mbox は、新しいメールが追加されていく単に1つのファイルで、フラグはそれぞれ のメッセージのヘッダに保存されます。メールを削除することは、残りのメッセージ で削除されたメールを上書きしなければならないので、とても遅いです。 メッセージフラグを変更することは、多くのデータをコピーすることを避けるための いくつかのトリックを使用するので、たいていとても早いですが、大きなデータのコ ピーと同様のことが起きるかもしれません。 コピーの遅さに加え、それは少し危険でもあります。もし、コピーを中断したら(ク ラッシュしたか、kill されたか、強制的に失われた)、メールファイルは駄目になっ た状態でどこかに残ってしまうでしょう。 結論: mbox は 読み込みのみのメールボックスには良く、 maildir は他の全てが良 い。 新しいユーザの作成 ------------------ Dovecot は1つのことだけに興味があります - ユーザのメールディレクトリを見つ けることができること。 maildir 形式では、 mkdir ~user/Maildir を行う必要があ り、 mbox 形式では mkdir ~user/mail です。 chroot を行う ------------- chroot することは、いくつかのセキュリティホールが発見された場合に備えて、 ユーザがシステムへフルアクセスすることを防ぐために、特別なセキュリティ強化と して使うことができます。もし間違って使うと、それはローカルユーザが root 特権 を得ることを許してしまうことにもなります。これは chroot jail の内部で sutuid バイナリをハードリンクし、それをだますことによって、可能になります。 少なくとも2つの可能性があります:独自の chroot/etc/passwd を作成し、 /bin/su を実行するか、もしくは独自の chroot/lib/libc.so を作成し、 setuid バ イナリを実行します。 もし chroot をしたいなら、 jail 内でローカルユーザが setuid バイナリにハー ドリンクできないことを確認してください。安全な方法として、そのファイルシステ ムに nosuid フラグを付けてマウントすることです。 ローカルユーザのシステム ------------------------ 例えば passwd-file を使うように、別に作成した IMAP パスワードや、デフォルト のシステムパスワードの両方を使うことができます。もしシステムパスワードを使用 するならば、 disable_plaintext_auth = yes にすることはとても良い考えです。 ローカルユーザではないシステム ------------------------------ 最初に、1つのシステム uid か、複数のシステム uid かどちら使いたいのか、決め る必要があります。例えば、1つをみんなで使うとき、それぞれの仮想ドメインで各 1つを使うのか、ユーザごとに1つをつかうか、です。いずれにしても、 uid は Dovecot の他の部分(login もしくは認証プロセス)で使われる uid と異なる必要が あります。 1ユーザにつき1つの uid を持たせることは、 Dovecot にセキュリティホールが あったとしても、ユーザが他人のメールを読めないということを意味します。できれ ば、これを使ってください。 imap プロセスを chroot することは良い考えですが、ファイルシステムを nosuid でマウントする必要があることを考えなければなりません。 パフォーマンス -------------- ほとんどの場合、 IMAP サーバのボトルネックはディスク I/O ですので、速いディ スクと、 OS のファイルキャッシュとして実行できるように多くのメモリを入手する ようにしてください。 パフォーマンス調整の1つの方法は、メールを LF の代わりに CR+LF で保存するこ とです。これは、メールを送信するときに、メールのインデックス作業が早くなり、 CPU の使用も少なくすむことができます。 Linux や FreeBSD や Solaris 9 では、 Dovecot はそのメールの送信に sendfile() システムコールを使用することができま す。しかし、余分な CR はメールのサイズを増やすことになるので、多くの I/O と 得られるはずのパフォーマンスを失うかもしれないことを意味します。 Dovecot を mail_save_crlf = yes と設定することにより、これを可能にすることができます。 メーラーで保存されたメールのために、他に何かする必要がありますが、この文章で は、まだ扱っていません。 COPY コマンドは maildir 形式で maildir_copy_with_hardlinks = yes の設定をす ることで、より早くなります。何かが1つのフォルダでメールを編集するが、それを 他から編集されたくない場合にのみ、これは問題を含みます。私は、直接メールファ イルを編集する MUA を知りません。 IMAP プロトコルもメールが変更されないこと を要求しているので、いずれにせよこれは問題を含むことになります。 ログインは、早さか、安全か、どちらかを扱うことができます。それを安全にすると いうことは、複数の接続を少しのプロセスで扱う代わりに、それぞれの接続の対して 新しい login プロセスを作成するということです。接続を共有することの問題は、 もしセキュリティホールが見つかった場合、攻撃者は他の人のコネクションを乗っ取 るか、plaintext 認証を使っていた場合(例えSSL/TLS であっとしても)、その人達の パスワードを盗むことができることです。もし、速さを望むならば、 login_process_per_connection = no に設定してください。 Dovecot のメモリーの使用は、かなり少ないです。 ps/top コマンドで見るほとんど 全てのメモリの使用は、 mmap されたファイルのもので、それは OS が、それをス ワップする必要がなく、いつでもそのメモリページのどれでも落とすことができると いうことを意味します。 Linux/x86 で Dovecot は通常、 mmap されていないメモリ に 70-100kB を取ります。 SORT や THREAD のようのいくつかのコマンドでは、より 多くのメモリを使用します(4600 通のメールを扱うのに 700kB ほどです)。 root なしの Dovecot ------------------- Dovecot は、いかなる点でも root 権限を必要とせずに、1つの uid の下で動作さ せることができます。これはセキュリティ機能は考えられていませんが、その代わり に管理者ではない人がお気に入りのメールサーバで IMAP サーバを動作させる方法に なります。 これを、セキュリティを達成する良い方法と考えているなら、どちらが悪いか考えて みてください: a) root 権限を得られる可能性がゼロに近く、ログインすることなく空のディレクト リに chroot された imapd ユーザとして、システムの中に入られるわずかな可能性 があり、ユーザの特権でログインされてしまうわずかな可能性はあるが、他の人の メールは異なる uid で保存されているため、読まれる可能性はありません(それに加 えて、自身のメールボックスに chroot されるかもしれません)。 b) Dovecot を経由して root 権限を得られる可能性はゼロで、メールユーザとして システムに入られるわずかな可能性と、ログインされずに、全てのユーザのメールを 読まれることができる可能性があります(そして最終的には、わざわざ特別な chroot 環境を設定しないかぎり、いくつかのローカルの脆弱性を発見されて exploit され ることにより、 root を得られるでしょう)。 どちらにしても、それは簡単にできます。 configure --prefix=$HOME とし、 make install をして、 dovecot.conf の login_user と auth_user をそのユーザの uid にし、全ての chroot を無効にし、 passwd-file 認証を使います。