Re: [Exim] message expiration

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Nico Erfurth
Ημερομηνία:  
Προς: Brian Bennett
Υ/ο: exim-users@exim.org
Αντικείμενο: Re: [Exim] message expiration
On Sat, 26 Oct 2002, Brian Bennett wrote:

> --
> Please help me.
>
> I have a mail server that is running completely out of control.
> I currently have 2476 messages queued to be sent, that is up by
> about 200 from this morning. I currently have 193 exim processes
> doing...something.


exiwhat will tell you what they do exactly, but 193 are too much for a
usual queue-run, until you raised the maximum queue-runners.

> My problem is that these messages are undeliverable and have been
> sitting in the queue for up to 25 days. I've been trying my damnedest
> to clear out my mail spool, but I just can't seem to do it. At first
> I was having a problem with users with very full mailboxes (some are
> as much as 65M). In order to attempt to help the situation I set a
> quota limit of 5M hoping that future messages would get rejected.


25 days is too much, are those messages all frozen?
try to set these options (exim4)
ignore_errmsg_errors_after = 3d <--- this deletes undeliverable bounces
                                     after 3 days
timeout_frozen_after = 7d       <--- this removes frozen messages older
                                     than 7 days from your queue, i'm not
                                     sure if they are bounced or removed
split_spool_directory           <--- Reduces the load a little bit
auto_thaw = 12h                 <--- to retry frozen messages after 12h


> Instead those messages generate errors and cause the origonal message
> to sit in the queue attempting re-delivery. The bounce message also


Please show us some log-entries and/or relevant parts of a debug-run.

> sits in the queue because the return e-mail address is often
> undeliverable as well.


you should use sender and receiver verification to deny messages to/from
undeliverable addresses.

> What I want is this:
> 1. Attempt delivery, if undeliverable, attempt retries for 24 hours.
> 2. If a message fails because a mailbox is over quota send a bounce
> and do not ever attept redelivery, delete it immediately.
> 3. Messages that are refused or timeout should never attempt
> redeliver, discard them imediately.


Why should it never happen?

> 4. After 24 hours, expire messages and delete them entirely.


They will be bounced, not deleted!

> 5. Above all, get it out of the queue at all costs!!!


Test the above settings first, and do
exim -qff to enforce a queue-run for ALL mesages.

> In my exim.conf I have this in the RETRY CONFIGURATION section:
> # Domain               Error       Retries
> # ------               -----       -------

>
> *                      quota


Thats ok.

> *                      refused
> *                      timeout


These both are BAD!
You should not use them, in todays internet you still get
delivery-problems, hotmail comes into my mind or even mail.exim.org was
unreachable for 24h last week.

> *                      *           F,2h,15m; G,8h,2h,1.5; F,24h,8h

>
>
> Exim seems to be completely ignoring me. What is wrong? What can I
> do to correct this? Why won't exim delete expired messages?!?


Set the above settings, the messages that are in your queue for more than
24 hours are most probably frozen messages.

> I'm using exim 3.35-1 on Debian 3.0 (woody). Please please please
> someone help me. As far as I can tell everything I've done is right,
> but exim just doesn't seem to care.


How does your queue-runner is started?
IIRC Debian starts it from crontab by default, which options does it use?

> At this point I'd settle for a nice perl script that will check
> the ammount of time a message has been on the queue and delete
> anything over 24 hours.


First try the above stuff, and please remove the retry-lines for refused
and timeout.

After setting these options in exim.conf run exim -qff and see what
happens.

If you still have much OLD messages in your queue, provide parts of your
mainlog and the relevant parts of a debug-run (exim -d9 -Mc MESSAGEID).

ciao