Authentication
--------------

See auth.txt.


Maildir or mbox?
----------------

Maildir stores each message into a separate file, message flags are stored
into file name. These make maildir very unlikely to get corrupted in any
way.

Reading lots of mails from maildir is somewhat slower than from mbox, since
each mail file needs to be separately opened. Updating the mailbox however
is much faster than with mbox.

With larger mailboxes it's a good idea to use a filesystem which uses
b-tree or hash indexes for directories, for example ReiserFS, XFS or JFS.
ext2 and ext3 have some patches to implement this but they're not in Linux
2.4.19 yet. I'm not sure about *BSD's filesystems, FreeBSD's ufs had some
support for hashes.

mbox is just a single file where new mails are appeneded, flags are stored
in each message's headers. Deleting mails is slow as the rest of the file
needs to be moved over the deleted mail. Changing message flags is usually
quite fast since we use some tricks to avoid copying too much data, but it
may result as well in large data copying.

Besides the copying being slow, it's also a bit dangerous. If the copying
is aborted (crashed, killed, power lost) the mail file may be left in
somewhat corrupted stated.

Bottom line: mbox is good for read-only mailboxes, maildir for everything
else.


Creating new users
------------------

Dovecot is interested in only one thing - being able to find the user's
mail directory. With maildir you need to do mkdir ~user/Maildir, with mbox
mkdir ~user/mail.


System with local users
-----------------------

First of all, don't make imap process chroot to users' mail directory,
UNLESS that filesystem is mounted with nosuid-flag. Otherwise there's a
small possibility for the user to gain root privileges.

Then you need to decide if you want users to have the same IMAP password
than the system password. If yes, disable_plaintext_auth = yes is a very
good idea.


System without local users
--------------------------

First you'll need to decide if you want to use one or multiple system uids.
For example one for everything, one per each virtual domain or one per each
user. In any case the uids should be different than the uids used for other
parts of Dovecot (login or auth processes).

Having one uid per user would mean that in case of a security hole in
Dovecot, the user still couldn't read other peoples mails. Use this if
possible.

chrooting imap processes would be good idea, but you should still think
about having the filesystem nosuid-mounted.


Performance
-----------

Usually the bottleneck with IMAP server is disk I/O, so get fast disks and
lots of memory to act as operating system's file cache.

One performance tweak is to save mails with CR+LFs instead of just LFs.
This can result in faster indexing of mails and smaller CPU usage when
sending mails. With Linux and FreeBSD Dovecot can use sendfile() syscall to
send such mails. However extra CRs do increase the mail size, meaning more
I/O and potentially losing the gained performance. You can enable this for
mails saved by Dovecot by setting mail_save_crlf = yes. For mails saved by
your mailer you'll need to do something else, not yet covered by this
documentation.

COPY command can be made much faster with maildir by setting
maildir_copy_with_hardlinks = yes. This is problematic only if something
modifies the mail in one folder but doesn't want it modified in the others.
I don't know any MUA which would modify any mail file directly.

Logins can be handled either fast or securely. Doing it securely means
creating a new login process for each connection instead of having only
few processes handling multiple connections. The problem with sharing
connections is that if a security hole is found, the attacker could hijack
other peoples connections or steal their passwords if plaintext
authentication was used (even with SSL/TLS). If you want to be fast,
set login_process_per_user = no.

Dovecot's memory usage is very small. Almost all memory usage you see with
ps/top is from mmap()ed files, meaning that operating system can drop any
of those memory pages at any time without needing to swap them. With
Linux/x86 Dovecot usually takes about 48kB of non-mmaped memory plus ~4kB
per cached mail, max. 16 by default, totaling around to 112kB.


Rootless Dovecot
----------------

It's possible to make Dovecot run under one uid, not requiring root
privileges at any point. This shouldn't be thought of as any security
feature, but instead just as a way for non-admins to run imap server from
their favourite mail server.

If you do think of this as a good way to achieve security, ask yourself
which is worse:

a) near-zero possibility to get root privileges, small possibility to get
into system as imapd user chrooted into empty directory without logging in,
small possibility to get logged user's privileges but no possiblity to read
others mails since they're saved with different uid (plus you might be
chrooted to your own mailbox).

b) zero possibility to get root privileges through Dovecot, small
possibility to get into system as mail user, possibly even without logging
in, and being able to read everyone's mail (and finally getting roots by
exploiting some local just discovered vulnerability, unless you bothered to
set up special chroot environment).

Anyway, doing it is easy. configure --prefix=$HOME, make install, change
login_user and auth_user in dovecot.conf to your user id, disable all
chrooting and use passwd-file authentication.