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

Inizio della pagina
Delete this message
Reply to this message
Autore: Stephen Gran
Data:  
To: Andreas Metzler, exim-users, Greg Kochanski, 270735-forwarded
CC: 
Oggetto: Re: [exim] Re: Bug#270735: exim4: Self-denial of mail service
This one time, at band camp, Andreas Metzler said:
> 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.


[snip]

> 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.


The obvious answer is don't allow people to run CPU intensive apps on
machines where getting your mail is important to you. If he has to do
this sort of thing, then set those values higher. There is IIRC a
$load_average available, so this could be tested for in acl's, and give
you a 'delay if too loaded' feature to slow incoming mail like sendmail
has. My vote is creeping featurism.

> 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?


Absolutely not - that's what the kernel VM is for. The kernel VM (at
least on linux) will hold as much of an app in memory as possible, and
swap it out if it needs to free up some memory. Sometimes all of the
memory is actively being used, and the kernel has to resort to the OOM
killer. How could exim possibly know whether or not memory being used
is able to be swapped out, or whether it is in active use? It is
technically possible to do these sorts of things, of course, but it is
absurd - much better to let the kernel do it's job and exim do it's job.
If the machine runs out of memory, don't worry - mail will be deferred
by the OOM killer :)

--
-----------------------------------------------------------------
|   ,''`.                         Stephen Gran |
|  : :' :                     sgran@??? |
|  `. `'            Debian user, admin, and developer |
|    `-                        http://www.debian.org |

-----------------------------------------------------------------