On 9.11.2010, at 23.49, Mark Moseley wrote:
On 9.11.2010, at 22.14, Mark Moseley wrote:
service imap { service_count = 0 }
Would the risks involved be identical to your warnings about using "service_count=0" with pop3-login/imap-login, namely that if the daemon gets hacked, it'd be able to access other mailboxes (presumably
On Tue, Nov 9, 2010 at 3:05 PM, Timo Sirainen tss@iki.fi wrote: that the imap/pop3 already had open)?
If all your users share the same UID and there was a security hole in imap/pop3, you could access everyone's mails regardless of this setting. (Except if you also enabled chroots, but then you couldn't use this setting.)
Nice, it does indeed seem to burn a lot less CPU. I've also set "process_min_avail=#" for 'service pop3' which appears to spread out incoming POP3 connections over all # pop3 procs. Any gotchas there? I've always got at least several hundred POP3 connections on a box, so having them not all hitting one proc is desirable. And having, say, 100 pop3 procs hanging around, possibly idle, is fine. This is pretty exciting stuff.
Should be fine.
Anybody running this way in production on a large scale, i.e. using "service_count=0" in a "service imap" or "service pop3" ?
Only potential problem is memory leaks that keep increasing the memory usage. Of course there should be no memory leaks. :) You could anyway set something like service_count=1000 to get it to restart after handling 1000 connections.