[Dovecot] v3.0 architecture

[Timo Sirainen]

I just had a thought. It's probably going to be too big of a change  
for v2.0, so something to think about for v3.0:

Supporting multiple UIDs is difficult. Currently expire-tool and  
v2.0's LMTP server are implemented in a way that it's always running  
as root and only temporarily dropping privileges. So any security hole  
in there gives the attacker root privileges. Not very nice. With a  
single UID it's possible (or will be) to just use that one UID for the  
process without running as root.

User sharing mailboxes to another user with different UID is even more  
difficult. Currently the only practical way to implement this is to  
assign read-write permissions to some group and have all mail files  
owned by that group. Not very nice.

Sharing mailboxes between users located in different servers is  
impossible if the disk isn't somehow shared.

All of these can be solved the same way:

1. imap, pop3, lmtp, etc. processes will be running without any  
privileges, very much like imap/pop3-login nowadays. Nobody-chrooted  
to empty directory.

2. Create storage processes that are started as needed. They can be  
configured in different security/performance settings: One storage  
process per user, one storage process per UID, setuid-root style  
shared storage process for multiple UIDs.

3. Mail processes talk to storage processes via some protocol. They  
can talk via UNIX socket or TCP/IP. If an existing connection can't  
handle the target UID, a new connection is made that either reuses an  
existing storage proces or creates a new one.

4. IMAP can finally implement truly simultaneously running queries  
(where it makes sense) by creating more storage processes if existing  
ones are busy handling longer-running commands. This also allows using  
the same storage process for multiple simultaneous IMAP connections  
and mail deliveries (and etc). The storage processes can also hang  
around and keep mailboxes open after all connections have closed it  
(dynamically figured out when it makes sense) to handle webmail  
clients that create lots of short-living connections or POP3 clients  
who poll for new mail every minute.

The big problem is what the protocol should be. Use some existing RPC  
protocol? It should be something extensible so that a plugin in imap  
process can talk to a plugin in storage process, without the base  
processes knowing anything about the details (e.g. imap-quota plugin  
asking quota usage from storage's quota plugin). In any case the  
client side API should be asynchronous. That can make it annoyingly  
difficult to use though. Wonder if I could switch to erlang or  
something for the imap/pop3 processes :)