http://dovecot.org/releases/2.0/alpha/dovecot-2.0.alpha1.tar.gz http://dovecot.org/releases/2.0/alpha/dovecot-2.0.alpha1.tar.gz.sig So here's the first alpha version of Dovecot v2.0. There are still a couple of things left to do, but in general it should work for most people. I started using it for my own mails a few days ago and it seems to work without errors. Largest changes since v1.2: * Global ACLs are now looked up using namespace prefixes. For example if you previously had INBOX. namespace prefix and a global ACL for "INBOX.Sent", it's now looked up from "INBOX.Sent" file instead of "Sent" as before. + Redesigned master process. It's now more modular and there is less code running as root. + Configuration supports now per-local/remote ip/network settings. + dsync utility does a two-way mailbox synchronization. + LMTP server and proxying. + Added mdbox (multi-dbox) mail storage backend. + doveadm utility can be used to do all kinds of administration functions. Old dovecotpw and *view utilities now exist in its subcommands. Some things left to do: - Do something about backwards compatibility with v1.x. Either make it read v1.x config files or provide some config conversion utility. - dsync still has some bugs - config process is a bit too slow. config handling in general could use some caching all around. no need to ask configuration for each login unless there are per-remote-ip settings. - some kind of an optional connection policy server could be useful. mainly to finally implement tcp-wrappers support. - mail_uid, mail_gid, mail_chroot settings don't really work now. I think this actually needs a bit larger change, which is probably a good idea in any case: After successfully authenticating, login process needs to get imap/pop3 process executed. Currently this is done by transferring the connection fd to master process, doing userdb lookup and then forking and execing the imap/pop3 process. The new behavior I'm thinking is that after auth, login process would connect to imap/pop3 unix socket in the login/ directory. That would cause master process to fork a new imap/pop3 process (running as root). Login process would send the necessary auth information via the unix socket, possibly transfer also the fd, and imap/pop3 would do the userdb lookup and then drop privileges. This change has some pros: - Master process will no longer temporarily hold some extra fds and use extra memory during auth lookups. If auth process is hanging these could cause problems. - Master process will no longer have any special auth handling code and I can remove type=auth-source and type=auth services. - Of course fixes the mail_* setting issue, because all of this is now done by imap/pop3 process, which knows about these settings. - Creating support for "multiple imap/pop3 post-login connections in a single process" should be pretty easy to implement with this. The imap/pop3 unix socket just needs to be listened by a new process in the middle that keeps track of what imap/pop3 processes exist and can redirect the new connections to those. But also some cons: - drop_priv_before_exec=yes no longer works, unless the uid/gid is hardcoded to the service {} block. - Each imap/pop3 process needs to do a connect() to auth server at startup, adding a bit to the latency.