[exim] Re: Bug#270735: exim4: Self-denial of mail service

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Andreas Metzler
Dátum:  
Címzett: exim-users
CC: 270735-forwarded, Greg Kochanski
Tárgy: [exim] Re: Bug#270735: exim4: Self-denial of mail service
Hello,
This is <http://bugs.debian.org/270735>. - I'll first quote the
original report unmodified and add my own thoughts below. (Please keep
270735@??? in cc on followups).

On 2004-09-09 Greg Kochanski <gpk@???> wrote:
> Several of the settings in exim4 can easily lead to accidental
> denial-of-service attacks on one's self.


> Specifically, setting deliver_queue_load_max, queue_only_load,
> smtp_load_reserve all will completely stop mail delivery if a user
> starts up some CPU-intensive program.     And, this can happen
> easily -- in a scientific/university environment, it's not unusual
> to start up a calculation that will take CPU-days to complete.


> So, one user can accidentally block mail service to other users (and
> himself, of course). To avoid this, you can't set these load limits
> much smaller than 3 or 4, and even then it's still possible (though
> unlikely) for the limits to be exceeded for days at a time.


> I suggest that what you really want is not for queueing and or
> delivery to be completely stopped when the load limits are exceeded,
> but to be slowed down, instead:
> deliver_queue_load_max pseudocode:
>     if( load > 2*deliver_queue_load_max)
>         abort_delivery()
>     else if(load > deliver_queue_load_max && random() > RAND_MAX/10)
>         abort_deliver()
>     deliver()


> On a system with light mail traffic, mail will then seep through,
> even if someone has loaded up the system with some CPU-intensive
> process. It's then possible to set deliver_queue_load_max to a
> reasonable value like 1.5 or 2, and have everything work in a
> sensible manner.


> Similar logic applies to smtp_load_reserve.  In the current
> definition, it is essentially useless on a system that is not a
> dedicated mail server without user shell access.  Again, one wants
> to accept a trickle of mail messages even if the computer is loaded
> up.  Here, though, random rejection is probably not the correct
> solution, because other systems don't retry often and will retry
> only a limited number of times.    There's a risk of completely
> losing mail, though it might be acceptably small if you used
> ...random() > RAND_MAX/4) instead of .../10).


> Instead, I think a good solution might be to maintain a file whose
> time-stamp is updated each time a SMTP connection is accepted, and
> then to check if it's been a while since the last connection.
> Pseudocode:
>     if(load > 2*smtp_load_reserve && !is_reserve_host())
>         DO_NOT_ACCEPT
>     else if(load > smtp_load_reserve && interval_since_last_smtp()<DELTA_T)
>         DO_NOT_ACCEPT
>     if(load > smtp_load_reserve)
>         update_smtp_time_stamp()
>     ACCEPT


> The same could be applied to queue_only_load, but the case is not as strong.


I am not sure what to make of this. Whether there is indeed a real
problem and whether the ideas make sense at all.

One of the obvious points is "reasonable value like 1.5 or 2". A
machine with load 2 (e.g. building two software packages) still can
receive and deliver mail without breaking into sweat, especially in
the scenario the submitter was targeting, e-mail just being one of
many services, i.e. rather light traffic.

I therefore tend towards "creeping featurism - wish denied", but I am
unsure and would rather hear more opinions.

Greg later wrote:
> Some spam filters, especially Bayesian filters, can take
> megabytes of memory. (I have one, which when loaded with
> 10000 spam messages and 10000 good messages, takes close to 100MB.)
>
> It makes sense, then, that exim have functionality to limit
> delivery when the free memory of the OS is very small.
> One could also limit SMTP acceptance when the free RAM
> is small and the system is starting to swap.


Should exim really have that fine grained knowledge for a specific
target platform (detect "when the free RAM is small and the system is
starting to swap") built in?

             thanks, cu andreas