Re: [exim] handling failures in pipes

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: W B Hacker
Fecha:  
A: exim users
Asunto: Re: [exim] handling failures in pipes
Ian P. Christian wrote:
> I'm delivering mail to cyrus in a pretty standard way:
>
> virtualuser_delivery:
>      driver = pipe
>      user = cyrus
>      group = mail
>      message_prefix = ""
>      message_suffix = ""
>      log_fail_output
>      return_output
>      envelope_to_add = true
>      command = "/usr/lib/cyrus/deliver -r $return_path $local_part@$domain"

>
>
> however....If cyrus is down for any reason, mail sent to users will be
> bounced with a message:
>
> couldn't connect to lmtpd: Connection refused
> 421 4.3.0 deliver: couldn't connect to lmtpd
>
> I would rather mail be accepted and stored locally untill cyrus is
> backup, bouncing the mail just because cyrus is down is not an option.
>
> How might I achieve this?
>
> Thanks,
>
>


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.

Then following that router with another that can store 'elsewhere' until cyrus
is back in action (rather than run out of usable routers).

In practice, holding in the queue for an uncertain duration awaiting cyrus
recovery may not be easily controllable, viz timeouts for other retries.

Providing alternative 'other than queue' storage is easy, but recovery and
re-injection to cyrus may be more difficult to 'safely' automate.

Unless you are prepared to do manual restoral, any of that may be more work than
doing whatever it takes to make sure cyrus doesn't fail in the first place.

AFAIK cyrus is not *inherently* unreliable, so that should be possible.

Bill