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
