On Tue, 2005-11-01 at 10:26 -0800, Blars Blarson wrote: > Package: exim > Severity: wishlist > > spohr.debian.org aka bugs.debian.org gets a lot of spam. Sometimes > spammers try to send large ammounts of spam at once from many > locations. spohr is currently suffering such an attack, with over > 18000 processes (almost all exim or exim3) and a load average of 64, > but still with 20% idle time. No mail is getting delivered. This > situation is an unintentional greylisting. Eventually the processes > time out and things get back to our normal 100,000 spams/day to filter > out a few hunderd non-spams from. (This has happended before.) > > What I would like to see is limits to how many exim processes run and > faster recovery when this type of DDOS attack happens. Since I don't > use exim, I don't know if it can be tuned better. Spohr is currently > running sarge, and the problem happend when it was running woody.
fwiw, upstream development on exim 3 (i.e. the version represented by the "exim" package) stopped over three years ago and the codebase is not going to get any further changes. However, a quick look through the 3.30 documentation gives the following, which may be of use (from http://www.exim.org/exim-html-3.30/doc/html/spec_11.html#IDX897): Since Exim has no central queue manager, there is no way of controlling the total number of simultaneous deliveries if the configuration allows a delivery attempt as soon as a message is received. If you want to control the total number of deliveries on the system, you need to set the queue_only option, which ensures that all incoming messages are simply added to the queue. Then set up an Exim daemon to start queue runner processes at appropriate intervals (probably fairly often, for example, every minute), and limit the total number of queue runners by setting the queue_run_max parameter. Because each queue runner delivers only one message at a time, the maximum number of deliveries that can then take place at once is queue_run_max multiplied by remote_max_parallel. Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]