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]

Reply via email to