Quick setup
-----------

If you use mbox, make sure that mbox_locks is set up the same way as rest
of your system.

Check client_workarounds and enable those you think you need.

If you need to create new SSL certificate, edit dovecot-openssl.cnf and
run mkcert.sh.

Going through settings in dovecot-example.conf is a good idea, they should
be well commented.


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.20 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.


Chrooting
---------

Chrooting can be used for extra security hardening to prevent users from
having full access to the system in case some security hole was found. If
used incorrectly, it can also allow local users to gain root privileges.
This is possible by hardlinking setuid binaries inside the chroot jail and
tricking them. There's at least two possibilities: create your own
chroot/etc/passwd and run /bin/su, or create your own chroot/lib/libc.so
and run any setuid binary.

If you want chrooting, make sure that no local users can hardlink setuid
binaries inside the jail. The safest way to do this would be to mount those
filesystems with nosuid flag.


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

It's possible to use either the default system passwords or create separate
IMAP passwords using eg. passwd-file authentication. If you use system
passwords, 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, FreeBSD and Solaris 9 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 mail files directly. IMAP protocol
also requires that the mails don't change, so it would be problematic in
any case.

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 70-100kB of non-mmaped memory. Some
commands such as SORT and THREAD will use more memory though (around 700kB
for threading 4600 mails).


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 in
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.