|
1214
|
1 Quick setup
|
|
|
2 -----------
|
|
|
3
|
|
|
4 If you use mbox, make sure that mbox_locks is set up the same way as rest
|
|
|
5 of your system.
|
|
|
6
|
|
|
7 Check client_workarounds and enable those you think you need.
|
|
|
8
|
|
|
9 If you need to create new SSL certificate, edit dovecot-openssl.cnf and
|
|
|
10 run mkcert.sh.
|
|
|
11
|
|
|
12 Going through settings in dovecot-example.conf is a good idea, they should
|
|
|
13 be well commented.
|
|
|
14
|
|
|
15
|
|
429
|
16 Authentication
|
|
|
17 --------------
|
|
|
18
|
|
|
19 See auth.txt.
|
|
|
20
|
|
|
21
|
|
|
22 Maildir or mbox?
|
|
|
23 ----------------
|
|
|
24
|
|
|
25 Maildir stores each message into a separate file, message flags are stored
|
|
|
26 into file name. These make maildir very unlikely to get corrupted in any
|
|
|
27 way.
|
|
|
28
|
|
|
29 Reading lots of mails from maildir is somewhat slower than from mbox, since
|
|
|
30 each mail file needs to be separately opened. Updating the mailbox however
|
|
|
31 is much faster than with mbox.
|
|
|
32
|
|
|
33 With larger mailboxes it's a good idea to use a filesystem which uses
|
|
|
34 b-tree or hash indexes for directories, for example ReiserFS, XFS or JFS.
|
|
|
35 ext2 and ext3 have some patches to implement this but they're not in Linux
|
|
1214
|
36 2.4.20 yet. I'm not sure about *BSD's filesystems, FreeBSD's ufs had some
|
|
429
|
37 support for hashes.
|
|
|
38
|
|
|
39 mbox is just a single file where new mails are appeneded, flags are stored
|
|
|
40 in each message's headers. Deleting mails is slow as the rest of the file
|
|
|
41 needs to be moved over the deleted mail. Changing message flags is usually
|
|
|
42 quite fast since we use some tricks to avoid copying too much data, but it
|
|
|
43 may result as well in large data copying.
|
|
|
44
|
|
|
45 Besides the copying being slow, it's also a bit dangerous. If the copying
|
|
|
46 is aborted (crashed, killed, power lost) the mail file may be left in
|
|
|
47 somewhat corrupted stated.
|
|
|
48
|
|
|
49 Bottom line: mbox is good for read-only mailboxes, maildir for everything
|
|
|
50 else.
|
|
|
51
|
|
|
52
|
|
|
53 Creating new users
|
|
|
54 ------------------
|
|
|
55
|
|
|
56 Dovecot is interested in only one thing - being able to find the user's
|
|
|
57 mail directory. With maildir you need to do mkdir ~user/Maildir, with mbox
|
|
|
58 mkdir ~user/mail.
|
|
|
59
|
|
|
60
|
|
977
|
61 Chrooting
|
|
|
62 ---------
|
|
|
63
|
|
|
64 Chrooting can be used for extra security hardening to prevent users from
|
|
1214
|
65 having full access to the system in case some security hole was found. If
|
|
|
66 used incorrectly, it can also allow local users to gain root privileges.
|
|
|
67 This is possible by hardlinking setuid binaries inside the chroot jail and
|
|
|
68 tricking them. There's at least two possibilities: create your own
|
|
977
|
69 chroot/etc/passwd and run /bin/su, or create your own chroot/lib/libc.so
|
|
|
70 and run any setuid binary.
|
|
|
71
|
|
|
72 If you want chrooting, make sure that no local users can hardlink setuid
|
|
|
73 binaries inside the jail. The safest way to do this would be to mount those
|
|
|
74 filesystems with nosuid flag.
|
|
|
75
|
|
|
76
|
|
429
|
77 System with local users
|
|
|
78 -----------------------
|
|
|
79
|
|
977
|
80 It's possible to use either the default system passwords or create separate
|
|
|
81 IMAP passwords using eg. passwd-file authentication. If you use system
|
|
|
82 passwords, disable_plaintext_auth = yes is a very good idea.
|
|
429
|
83
|
|
|
84
|
|
|
85 System without local users
|
|
|
86 --------------------------
|
|
|
87
|
|
|
88 First you'll need to decide if you want to use one or multiple system uids.
|
|
|
89 For example one for everything, one per each virtual domain or one per each
|
|
|
90 user. In any case the uids should be different than the uids used for other
|
|
|
91 parts of Dovecot (login or auth processes).
|
|
|
92
|
|
|
93 Having one uid per user would mean that in case of a security hole in
|
|
|
94 Dovecot, the user still couldn't read other peoples mails. Use this if
|
|
|
95 possible.
|
|
|
96
|
|
|
97 chrooting imap processes would be good idea, but you should still think
|
|
|
98 about having the filesystem nosuid-mounted.
|
|
|
99
|
|
|
100
|
|
|
101 Performance
|
|
|
102 -----------
|
|
|
103
|
|
|
104 Usually the bottleneck with IMAP server is disk I/O, so get fast disks and
|
|
|
105 lots of memory to act as operating system's file cache.
|
|
|
106
|
|
|
107 One performance tweak is to save mails with CR+LFs instead of just LFs.
|
|
|
108 This can result in faster indexing of mails and smaller CPU usage when
|
|
977
|
109 sending mails. With Linux, FreeBSD and Solaris 9 Dovecot can use sendfile()
|
|
|
110 syscall to send such mails. However extra CRs do increase the mail size,
|
|
|
111 meaning more I/O and potentially losing the gained performance. You can
|
|
|
112 enable this for mails saved by Dovecot by setting mail_save_crlf = yes. For
|
|
|
113 mails saved by your mailer you'll need to do something else, not yet
|
|
|
114 covered by this documentation.
|
|
429
|
115
|
|
|
116 COPY command can be made much faster with maildir by setting
|
|
|
117 maildir_copy_with_hardlinks = yes. This is problematic only if something
|
|
|
118 modifies the mail in one folder but doesn't want it modified in the others.
|
|
977
|
119 I don't know any MUA which would modify mail files directly. IMAP protocol
|
|
|
120 also requires that the mails don't change, so it would be problematic in
|
|
|
121 any case.
|
|
429
|
122
|
|
431
|
123 Logins can be handled either fast or securely. Doing it securely means
|
|
429
|
124 creating a new login process for each connection instead of having only
|
|
|
125 few processes handling multiple connections. The problem with sharing
|
|
|
126 connections is that if a security hole is found, the attacker could hijack
|
|
|
127 other peoples connections or steal their passwords if plaintext
|
|
431
|
128 authentication was used (even with SSL/TLS). If you want to be fast,
|
|
|
129 set login_process_per_user = no.
|
|
429
|
130
|
|
|
131 Dovecot's memory usage is very small. Almost all memory usage you see with
|
|
|
132 ps/top is from mmap()ed files, meaning that operating system can drop any
|
|
663
|
133 of those memory pages at any time without needing to swap them. With
|
|
997
|
134 Linux/x86 Dovecot usually takes about 70-100kB of non-mmaped memory. Some
|
|
|
135 commands such as SORT and THREAD will use more memory though (around 700kB
|
|
977
|
136 for threading 4600 mails).
|
|
429
|
137
|
|
|
138
|
|
|
139 Rootless Dovecot
|
|
|
140 ----------------
|
|
|
141
|
|
|
142 It's possible to make Dovecot run under one uid, not requiring root
|
|
|
143 privileges at any point. This shouldn't be thought of as any security
|
|
977
|
144 feature, but instead just as a way for non-admins to run imap server in
|
|
664
|
145 their favourite mail server.
|
|
429
|
146
|
|
|
147 If you do think of this as a good way to achieve security, ask yourself
|
|
|
148 which is worse:
|
|
|
149
|
|
|
150 a) near-zero possibility to get root privileges, small possibility to get
|
|
|
151 into system as imapd user chrooted into empty directory without logging in,
|
|
|
152 small possibility to get logged user's privileges but no possiblity to read
|
|
|
153 others mails since they're saved with different uid (plus you might be
|
|
|
154 chrooted to your own mailbox).
|
|
|
155
|
|
|
156 b) zero possibility to get root privileges through Dovecot, small
|
|
|
157 possibility to get into system as mail user, possibly even without logging
|
|
|
158 in, and being able to read everyone's mail (and finally getting roots by
|
|
664
|
159 exploiting some local just discovered vulnerability, unless you bothered to
|
|
429
|
160 set up special chroot environment).
|
|
|
161
|
|
|
162 Anyway, doing it is easy. configure --prefix=$HOME, make install, change
|
|
435
|
163 login_user and auth_user in dovecot.conf to your user id, disable all
|
|
|
164 chrooting and use passwd-file authentication.
|
