Alf Schlichting wrote:
We had a similar problem on our mailserver and thunderbird as mail client.
Basicly, thunderbird has a certain timeout value for searches. If thunderbird
doesn't get a result for a search after <timeout> seconds, it assumes some
error and requests the search again. new search -> new fork -> more load
and so on. Other MUAs may have similar settings. Solution:
Search and set the timeout value in thunderbird's config editor
(IRC mailnews.tcptimeout, defaults to 60)
Alf, thanks, and thumbs up. It is not so much of a fault of OpenBSD as
it is on courier-imap and thunderbird.
I did have to restart Thunderbird to make mailnews.tcptimeout actually
use 600 seconds, which is sick otherwise. But after some 2.5 minutes it
had nicely found the string in 'Entire Message', and otherwise behaved:
no forking, no too high load.
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.
With the larger part of the blame on courier-imap, because it does not
seem to honour its own limit of 4 or 5 sessions per IP:
# Maximum number of connections to accept from the same IP address
MAXPERIP=4
Also, Thunderbird surely needs two dials: mailnews.tcptimeout is pretty
much okay with 60 seconds default, but its mistake is to consider a
search-still-in-the-making as 'connection failure'. And to spawn a new one.
Use smaller inboxes
Get more iron:)
Sorry, no. We need to do better than allowing an easy DoS. The lever
must not be iron or size, it needs to be predictable and always
reasonable behaviour of the softwares.
Thanks again, would have never found the problem on my own!
Uwe
