[Dovecot-news] v2.0.alpha1 released


dovecot.org/releases/2.0/alpha/d … ha1.tar.gz
dovecot.org/releases/2.0/alpha/d … 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

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.