Re: [exim] Retry rules, feature request

Philip Hazel wrote:

> On Tue, 11 Jul 2006, Stefan Klatt wrote:
>
>
>>And if the retry rule is used.. at this point the information about the
>>error must be there !?!
>
>
> Yes. But the retry rule is not used at the time the bounce message is
> sent. *That* is the point. (And it's retry ruleS - may be more than one
> host involved. And indeed there may be more than one address involved
> when the bounce message is sent.)
>
> What I am trying to say is that (a) I think this is quite a bit of
> design work, and then an unknown quantify of implementation work and (b)
> I don't have the time to look in detail.
>
>
>>It there is an error like tls_reiquired i think any admin want to see
>>this error immediatly.
>
>
> Most admins get this kind of information by watching the queues, not by
> receiving emails.
>
> There is no reason why this suggestion should not be added to the Exim
> Wish List, of course, but I do not think I am likely to look at it in
> the foreseeable future. Sorry about that, but there are only so many
> hours in the day.
>
>

What Stefan is asking for falls, IMNSHO, in the category best addressed with
*external* diagnostics, already well served.

- first, as PH has stated in another way, it covers an issue that is seldom
problematic.

- secondly, looking at what retry rule(s) activate is viewing the symptom, not
the cause. There is usually a causal pattern - flakey far-end, flawed local
router, broken local user entry, or such - that gives rise to a need for a retry.

Exim can already log Queue time and Delivery time. A grep/exigrep or eximstat
will show that a retry is not a common event on well-configured servers. The
majority of traffic succeeds on first attempt.

One may easily select the few overly long queue times to see if retry has been
involved. Most such will show problematic destinations or other common cause,
often a blindingly obvious one.

One may examine the source, destination, protocols, and message format & content
in more detail to see if whatever caused the delay / retry is correctable on the
Exim server.

Once local config errors and far-end problems are removed, fewer than one
message in several thousand should remain 'mysterious' as to retry.

For modern SME business use, where a critical communication needs to be followed
up 'same day' or 'same hour' by fax or phone, not next Tuesday, we have
configured servers to 'final fail' on retry in as little as 13 minutes, not 3 or
4 days. It is still an exceedingly rare event.

Bill Hacker