On 22.6.2012, at 5.28, email builder wrote:
>> Oh, and of course it also depends on Dovecot configuration :) Authentication
>> cache is needed and login processes must be in high performance mode.
>
> I.e., I think:
>
> http://wiki2.dovecot.org/LoginProcess
> http://wiki2.dovecot.org/Authentication/Caching
Yes.
>> There is
>> still the extra work of forking a new imap process (could also be avoided
>> with
>> yet another config option)
>
> Are you referring to client_limit or service_count or something else as yet
> undeveloped?
service imap { service_count = 0 } (default=1) allows imap processes to be
reused for more than 1 connection. The downside is that if there are any bugs
in Dovecot, they might accidentally expose another user's email data to the
wrong user. That's very unlikely to happen but since this isn't a performance
problem in most (if any) systems I don't want to enable it by default. Dovecot
code is written so that write buffer overflows (= arbitrary code execution) is
minimized to be as zero possibility as I could think of, but read buffer
overflows (= exposing data within the process) isn't treated nearly as much
with paranoia.
> Speaking of which, I cannot understand the different between those two.
> Hints in the
> configuration file (10-master.conf) and the wiki make them sound like they do
> the same
> thing -- ??
service_count limits the maximum of client_limit. One connection = one service.
Once a process has serviced "service_count" number of connections it
disconnects itself. There can never be more than "client_limit" number of
simultaneous connections. The important stuff to understand about these are:
* service_count=1: The most secure setting for a process. The process serves a
single connection and kills itself. No possibility of data leaking to
unintended connection.
* service_count=0, client_limit=1: The process does blocking operations (e.g.
blocking disk IO). You don't want one connection's blocking operation to affect
other connections. But you're not paranoid about security, since in case of
some bugs some data might leak to unintended connection.
* service_count>0: Restart process ever N connections, just in case it leaks
some memory.
* client_limit>1: Limit the amount of CPU/memory a single process takes. The
process should never be blocking on disk I/O or locks or anything else. This
means it shouldn't be used for imap/pop3/lmtp processes. For CPU bound
processes it's fine.
Maybe these could be copy&pasted to the wiki2/Services.
