System users are typically defined in
/etc/passwd file, but this
isn’t necessary. Using
NSS you can
configure the lookups to be done from elsewhere (e.g. LDAP). See
userdb configuration for how to set this up. Especially if you’re using
nss_ldap you must set
System users usually have their own separate user IDs (UIDs). This is good from a security point of view, because it means that the kernel will also prevent users from accessing each others’ mails.
If the users have direct write access to the mail files (eg. the users have shell access), they can easily cause all sorts of mailbox corruptions. That may generate all kinds of error messages to Dovecot’s error logs, so it may be sometimes difficult to tell if there really is a problem or if the user is doing something stupid.
If users are going to access the mailboxes with other software than Dovecot, it’s important to make sure that their mailbox accesses are compatible. This mostly means that with mboxes you must make sure that everyone uses the same locking methods in the same order.
Admins often wish to use different passwords for IMAP and POP3 than for other services (eg. SSH), because IMAP and POP3 clients often send the password unencrypted over the internet without even bothering to give users any warnings. Dovecot can easily support non-system passwords for system users.
If you wish to use system passwords, you’ll want to use one of these passdbs:
PAM: Most commonly used in Linux and BSDs nowadays.
BSDAuth: BSD authentication is used by OpenBSD.
Passwd: System users (NSS,
/etc/passwd, or similar). This may work instead of PAM (mostly in some BSDs).
Usually UNIX systems are configured by default to deliver mails to
/var/spool/mail/username mboxes. You may
decide to use these, or use the maildir format instead.
Dovecot detects the mailbox format and location automatically if
mail_location setting isn’t set, but it’s still a good idea to
explicitly tell Dovecot where to find the mails. This ensures that
Dovecot behaves correctly also when the user’s mailbox doesn’t exist at
the moment (eg. a new user). If Dovecot can’t figure out where the
existing mails are, it will give an error message and quits. It never
tries to create a missing mailbox when autodetection is used.
See Mail Location Settings for more information how to configure the mailbox location. Below are the highlights for mbox and maildir.
/var/mail/username mbox is called user’s INBOX. IMAP protocol
supports multiple mailboxes however, so Dovecot needs some directory
where to store the other mailboxes. Typically they’re stored in
~/Mail/ directory. All of these locations are
included in mailbox location autodetection. You can specify them
mail_location = mbox:~/mail:INBOX=/var/mail/%u
Remember that the first path after
mbox: is the mailbox root
directory, never try to give
mbox:/var/mail/%u because that
isn’t going to work (unless you really want to store mails under
If you’re also using other software than Dovecot to access mboxes, you
should try to figure out what locking methods exactly they’re using and
accordingly. See locking section in mbox for
Maildir is typically stored in
~/Maildir directory. You can specify
this manually with:
mail_location = maildir:~/Maildir
See Maildir Mailbox Format for more information.
Dovecot, including several other software, allow using “/./” in home
directory path to specify the chroot path. For example
would chroot to
/home. If you want to enable this for Dovecot, add
the chroot path to
valid_chroot_dirs setting (
/home in the
previous example). If this isn’t done, Dovecot ignores the “/./”.
See Chrooting for more details.