> Do you think [moving IMAP IDLE connections to a separate imap-idle process] > would work for you also?
Probably. It always depends on the details. Forking a new imap process every time there's a little input to read or output to send might perform poorly under load. Having a pool of ready imap processes could help that, when the configuration permits (e.g. all mail owned by one uid). It would be interesting to compare client_limit > 1 vs. an idle connection aggregator. What's so evil about client_limit > 1 besides requiring one uid, the indexer polling I mentioned, and broken fcntl-style file locks? Or is that enough?
