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-news/attachments/20091012/72df41a3/attachment.bin