[Dovecot] v2.0.alpha1 released

[Timo Sirainen]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20091012/72df41a3/attachment.bin