[EXIM] Preventing mail spool from filling up

Top Page
Delete this message
Reply to this message
Author: Stuart Lynne
Date:  
To: exim-users
Subject: [EXIM] Preventing mail spool from filling up
> check_spool_space and associated configurations don't answer the original
> question as I understand it. The original question was about filling up
> the partition of filesystem with the actual mailboxes, say
> /var/spool/mail) and not of Exim's spool directory, say /usr/spool/exim .
>
> As your quote from the manual said.
>
> On Tue, 1 Jun 1999, Microwave Systems Eximlist Exploder wrote:
>
> >     The four check_... options allow for checking of disc resources
> > [...]
> >     The spool partition is the one which contains the directory defined
> > by SPOOL_DIRECTORY in Local/Makefile.

>
>
> This is NOT typically where delivery occurs. Yes, we all know that
> the traditional name for that, /usr/spool/mail, does say spool in it, but
> that is misleading.
>
> So, I think the question is whether exim can be configured to check and
> warn about free space in delivery partitions. If something like that were
> to exist, it should presumably be added to the appendfile transprot, since
> that is when it knows what partition it is delivering to. A quick look at
> the specs (2.12) suggests that no such feature exists.
>
> I could imagine a feature that allows a delivery threshold in for
> appendfile, but as far as I can see, all it would do is effectively cut
> down your partition size. That is, exim will fail to deliver and defer if
> the partition is 100 percent full anyway. So what is gained by setting
> things up to do that when the partition is 95 percent full unless you've
> got other things going on on that partition?


It appears that exim still only checksfor available space before accepting a
message. This is to ensure that there is sufficent space to accept a
message. It is only a best estimate though as we don't know how big the
incoming message is. So you set it high enough that other than for very
large messages things will be ok.

It would not be hard and it might be a good idea, to do the same check
before attempting delivery. In general though if appendfile fails to
correctly deliver the message it is supposed to DEFER the message. So it may
be sufficent to simply try, fail, and then DEFER. Instead of test, DEFER.


--
*** Exim information can be found at http://www.exim.org/ ***