Software: Apache/2.0.54 (Fedora). PHP/5.0.4 uname -a: Linux mina-info.me 2.6.17-1.2142_FC4smp #1 SMP Tue Jul 11 22:57:02 EDT 2006 i686 uid=48(apache) gid=48(apache) groups=48(apache) Safe-mode: OFF (not secure) /usr/share/doc/dovecot-0.99.14/ drwxr-xr-x |
Viewing file: Select action/file-type: 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. |
:: Command execute :: | |
--[ c99shell v. 1.0 pre-release build #16 powered by Captain Crunch Security Team | http://ccteam.ru | Generation time: 0.0027 ]-- |