[Dovecot] Advice for new dovecot / imap proxy? setup

[Luca Lesinigo]

Hello list.

I'm planning a new mail servers for our company's customers to replace the oldish Courier-IMAP based one, we already started to deploy some mail accounts on a dovecot-2.0 server as an early test.
I'd like to implement the new system with dovecot-2 (I'll probably go straight to dovecot-2.1.x) and I'd like to get it right from the beginning so I'm here asking for some advice.

The issue I'm investigating right now is how to manage a single IMAP / POP / SMTP / webmail  "entry point" for multiple mail servers... in other words an IMAP proxy.
It would be desirable for multiple reasons:
- graceful migration from the current system: we'd make the mailserver hostname point to the proxy (along with its SSL certificates) and then the proxy would route each domain to the correct IMAP non-ssl server on our LAN. No need to update customer's systems configuration and we can move one domain at a time from the old to the new server, behind the scenes
- be ready for similar migrations in the future (eg. right now we're still keeping the imap servers with the qmail MTA, but we'd like to switch to postfix+dovecot in the future)
- be ready for sharding mail domains on multiple IMAP servers (if/when current hardware reach its capacity or needs to be swapped out for new gear)
- be ready to serve traffic over IPv6 without touching our precious mailbox servers
- isolate the mailbox servers from direct external access and just run IMAP on them, let other systems run ssl, pop3, smtp, webmail, etc...

Ideally the 'proxy' system would run dovecot imap and pop3 (SSL protected) and Roundcube webmail (PHP, on https) and just speak IMAP to the underlying mail servers on our internal LAN.
We'd like to support all the recent IMAP goodies to make modern users happy (IMAP IDLE, LEMONADE, etc) and possibly implement Maildir quota on the new backend mailbox server to improve our operations (currently we just run du in a cronjob once a day on the current mailserver, IMAP clients including the webmail do not know about quota and thus cannot show amount of free space).

In addition to that, customer's will hit the SMTP server running on that 'proxy' system and this is good to keep its configuration separated from the SMTP server of the actual mail servers (which has a different configuration and is restricted to get connections only from our MX systems and not from outside sources).

I'd like to know if that plan sounds reasonable or if there's something stupid in it.
Also, is the proxy going to support all kind of IMAP stuff of the backend server (IDLE, CONDSTORE, Maildir quota, immediate notification of IDLE clients thanks to linux inotify, etc...) or will it limit me somehow?

thanks,
--
Luca Lesinigo