Bug#270735: marked as forwarded (exim4: Self-denial of mail service)
Debian Bug Tracking System
owner@bugs.debian.org
Sat, 11 Sep 2004 06:48:09 -0700
Your message dated Sat, 11 Sep 2004 15:35:31 +0200
with message-id <20040911133531.GA22976@downhill.at.eu.org>
has caused the Debian Bug report #270735,
regarding exim4: Self-denial of mail service
to be marked as having been forwarded to the upstream software
author(s) exim-users@exim.org.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
---------------------------------------
Received: (at 270735-forwarded) by bugs.debian.org; 11 Sep 2004 13:35:37 +0000
>From eximusers@downhill.at.eu.org Sat Sep 11 06:35:37 2004
Return-path: <eximusers@downhill.at.eu.org>
Received: from server.logic.univie.ac.at [131.130.190.41] ([N2zQUycbXIOaHoitIeQ5Jjjfe4s0u/wK])
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1C682T-00089b-00; Sat, 11 Sep 2004 06:35:37 -0700
Received: from m-134-246.adsl.univie.ac.at ([131.130.134.246])
by server.logic.univie.ac.at with asmtp (Exim 4.34)
id 1C682L-00074q-UY; Sat, 11 Sep 2004 15:35:32 +0200
Received: from ametzler by downhill.univie.ac.at with local (Exim 4.34)
id 1C682N-0005zb-93; Sat, 11 Sep 2004 15:35:31 +0200
Date: Sat, 11 Sep 2004 15:35:31 +0200
From: Andreas Metzler <eximusers@downhill.at.eu.org>
To: exim-users@exim.org
Cc: Greg Kochanski <gpk@kochanski.org>, 270735-forwarded@bugs.debian.org
Subject: Re: Bug#270735: exim4: Self-denial of mail service
Message-ID: <20040911133531.GA22976@downhill.at.eu.org>
Mail-Followup-To: Andreas Metzler <eximusers@downhill.at.eu.org>,
exim-users@exim.org, Greg Kochanski <gpk@kochanski.org>,
270735-forwarded@bugs.debian.org
References: <E1C5By1-0005zZ-Na@gpk.phon.ox.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1C5By1-0005zZ-Na@gpk.phon.ox.ac.uk>
X-GPG-Fingerprint: BCF7 1345 BE42 B5B8 1A57 EE09 1D33 9C65 8B8D 7663
User-Agent: Mutt/1.5.6+20040722i
Sender: Andreas Metzler <ametzler@downhill.at.eu.org>
Delivered-To: 270735-forwarded@bugs.debian.org
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=no
version=2.60-bugs.debian.org_2004_03_25
X-Spam-Level:
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@bugs.debian.org in cc on followups).
On 2004-09-09 Greg Kochanski <gpk@kochanski.org> 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