Large scale Unix/Linux mail solution comes to a bottleneck of performance where maximized on scale in solution. Scale out solution is usually based on clusterFS/NFS for maildir but read cache kills your file system always.After scaled out, you will have more than one mail server that are working on one NFS server for maildir. That is the problem! Since most of the mail client solutions are multi-tasking. Even only one email account, it will open several connections at the same moment. If these connections are made into different mail server, the cache gives you a chance to obtain an error or to corrupt the file system. Please remember, the cache with around 60sec is a default (check with mount options for nfs3). To avoid this corruption, you have to turn off the cache by actimeo=0 option. Unfortunately, the performance will be downgraded 10 times or more with this option. If you use the sar or vmstat to monitor, you will be bored because high idle time with almost no cpu and i/o wait. It is because the read access (yes, performance problem not on write but corruption is) without cache. You can check by listing a directory with 10000 files. It may takes more than 10 seconds. It is horrible.
As a result, NFS is not a solution. You may try using VxFS or OCFS2. These kind of file system has cache coherent and clustered flock technology. Not like NFS, the update and lock request is directly sent to other nodes by multicast. However, the best solution is to avoid updating the same file or directory on different machines until the current machine is dead.
For IMAP/POP3 mail client access, you can think about using dovecot director. It comes with dovecot and very easy to configure. It is load balance available. You can install more than one in your infrastructure. Yes, it helps you great when using SSL. The SSL encryption/decryption workload will be on the dovecot director, then, proxy the raw request to backend mail server. The director has a table to maintain the user => mail server mapping. Each time a request to the director will be proxy to the same backend mail server, always. So, updating the same file and directory case will be cut down to minimal. How about the smtp? Try using the LMTP, it is easy with a mailbox_command on Postfix.
Unfortunately, the version 2.0.x of dovecot director is not a HA solution. It assumes the backend is always up!? When one of the backend mail server down, the direct knows nothing and still forward the request on it. Timeout setting does NOT HELP on you. It is because the last update mechanism is definitely a BUGS. When a request from the mail client is being made, the last update time will be marked no matter the backend access is good or fails.
You MUST use some manual work-a-round on director solution to monitor the backend server status and flush the mapping when status changed. I wish the version 2.1.x would have such monitoring mechanism.