Re: [Exim] Timing out frozen messages

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Michael J. Tubby B.Sc. G8TIC
Ημερομηνία:  
Προς: exim-users
Αντικείμενο: Re: [Exim] Timing out frozen messages
> Recent postings from Graeme Wilford and Alan Thew have brought to light
> an unintended change that I made at release 3.14 (change 8). I
> re-organized the way Exim handles the "ultimate address timeout" to fix
> a problem, but this had the following side-effect:
>
> If a bounce message fails and gets frozen because ignore_errmsg_errors
> is not set, manual or auto thawing won't get rid of it (assuming it
> continues to fail). It just gets frozen again. However, if you use
> ignore_errmsg_errors_after, it will be discarded after that has kicked
> in and caused another retry.
>
> The previous machinery would ultimately clean such things up even in the
> absence of ignore_errmsg_errors_after. After some thought, I have
> decided that there is no need to reinstate the (rather inelegant) rule I
> had before. It seems to me that the existence of

ignore_errmsg_errors_after
> is now a sufficient way of dealing with these messages. It might even be
> a good idea to put something like ignore_errmsg_errors_after=7d into the
> default configuration.
>
> However, this made me think about frozen messages that are not failed
> bounces. These can be a result of freezing in the system filter, or
> freezing because Exim has hit something unexpected. As long as they
> continue to get frozen, these messages will never go away, even if
> auto-thawed regularly.
>


This is why my mail queue was growing on post.thorcom.com as
a result of hitting various forms of undeliverable conditions for
subscribers
of some of our mailing lists, and ultimately caused me to ask you for a
exim "remove frozen messages from queue" command, which in turn resulted
in a discussion on the virtues of an "exipick" function.... instead I
cobbled
some perl to clean my queue.

> The normal timeout mechanisms ensure that non-frozen messages will
> ultimately fail. It seems to me that perhaps there should be an explicit
> way of timing out frozen messages. The simplest would be to introduce a
> new option, e.g.
>
> timeout_frozen_after = 5d
>
> This would operate like this: if a queue runner found a frozen messsage
> that was that old, it would get rid of it, in one of two ways:
>
>   (a) If the message is not a bounce message, it will generate a bounce,
>       exactly as if the -Mg option had been used to force Exim to give
>       up.

>
> (b) If the message is a bounce message, it will just discard it.
>
> Anybody like to comment?
>


Great idea - I'll have two please! Seriously, thou, can you deliver it
yesterday?


Mike