Re: [exim] handling failures in pipes

Top Page
Delete this message
Reply to this message
Author: W B Hacker
Date:  
To: exim users
Subject: Re: [exim] handling failures in pipes
Ian P. Christian wrote:
> On 11/01/06 W B Hacker wrote:
>> In theory by adding a 'fall-through' conditional on the above router
>> that checks for cyrus availability so it doesn't accept then return a
>> failure.
>
> Thanks for your response.
>
> I'm a little puzzled by why exim doens't provide a solution to handle
> this itself. If a 'smtp' transport fails, things are added to the mail
> queue. Why is this not the case when a pipe files?


The smtp process is near-as-dammit fully under Exim's control.

A pipe is, by definition, something NOT fully under Exim's control.

You could be using it to trigger turning on a coffee maker
by e-mail message.

> Shouldn't this behaviour be configurable?
>


To such extent as is *possible*, or practical, it is.

However, the possibility for a 'pipe' being essentially bounded only by the OS,
peripherals, and creative mind of man, i.e. finite, but large,

'return_error'

is about all that can be provided for the general case.

Anything more clever or specific requires crafting bespoke handling of that
return - or even lower-level coding.

>
> Cyrus is reliable, however I lost 6 mails today to bounces(out of
> 50,000, it's not much but it does matter) beause cyrus was unavailiable
> for some reason.


Logs of both turned up to high verbosity levels will almost certainly
ID that reason, and rapidly.

Fixing it, my guess only, will probably have to do with fs or
other resource contention.

>
> I understand I might be able to set the 'temp_errors' option to defer
> the sender with a 'try again later' response rather then a perminent
> error, but ideally I should be able to get exim to handle a 'pipe'
> failure in the same way it handles a 'smtp' error, and just put it in
> the queue for later processing.
>


Spec says Exim basically 'ticks off' recipients at each successive
delivery pass (or the only such pass), destroys the queue copy only
once the last one left returns successful delivery.

Not sure how well that flies with a pipe. If/as/when Exim
understands the pipe to have accepted it, color it 'GONE'.

Hence the general case for return_error.

Bill