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 :)
