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.