On Fri, Jul 25, 2008 at 11:11:50PM +0800, Uwe Dippel wrote: > Federico G. Schwindt wrote: >>> It is a nice DoS-combo, what courier-imap in conjunction with >>> Thunderbird offer here, and one doesn't even need local access. Just >>> any remote Thunderbird client will do, and we can't prevent the user >>> from drag&drop some tens of thousands of messages into a folder. Or, >>> even easier, reduce mailnews.tcptimeout, and we get one new process >>> per one second. Sick. >>> >> >> This is not a DoS, just a configuration issue. >> Have you tried changing the class to something else than daemon? >> > > Which one? I used default, and it doesn't make a difference. Okay, I > didn't let it drive up loads of 80. Simply stopped around 7, once some 8 > processes were running. > Still, I wonder why it won't stop at 4, despite -maxperip=4 > If it was a configuration problem, I'd have to create an extra, very > restrictive login class for it. And then, the install message should say > so. And even then, with > maxproc=10 > I'd get loads of close to 10, and no result forever. > > I'm not an email expert, but I'd think that firstly, it should actually > limit the sessions per IP, not the number of processes: If you have 10 > users on, they might get well 5 processes each. If there was only 1 > user, he still ought not get 50 processes. > Furthermore, it should limit to one search per user login at a time. > Then, whatever the setting of the client, there would be one search > coming to a proper end before another could be spawned.
I was talking about OpenBSD and "cannot fork" part. Clearly courier-imap is the one to blame here. f.-
