[exim] Re: Errors in transport filters

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Felix Schwarz
Dátum:  
Címzett: exim-users
Tárgy: [exim] Re: Errors in transport filters
Kjetil Torgrim Homme wrote:
> On Thu, 2005-12-08 at 09:50 +0100, Felix Schwarz wrote:
>
>>My script does not send any mails. It is just a filter that changes a
>>mail in certain way. After that the output (RFC 822 email) should be
>>handed over to Exim again. Exim will handle the actual delivery.
>
>
> why are you using a pipe delivery?


It seems that this is the easiest way to do spam checking without using Amavis
oder MailScanner which do not provide the features I need. Furthermore I wanted
to avoid extra efforts in order to handle errors (e.g. database down) and Exim
has already mechanisms for that (deferring the delivery, queue runner process).

>>What Exim does is: It takes the mail, calls the transport filter script.
>>This script will return a non-zero exit code
>
>
> "A non-zero code is taken to mean that the transport filter failed in
> some way. Delivery of the message is deferred."
>
> however, since you are invoking exim as a pipe delivery, that child exim
> will run to completion with whatever input it receives. (my
> understanding, not verified.)


This explanation matches obviously the current implementation. In my
understanding "Delivery of the message is deferred." means that there is no
delivery.

> Philip, I think perhaps the documentation for transport_filter should be
> clearer about whether transport_filter and pipe_command are run in
> parallel or sequentially.


Maybe I should look at the code but my mental model was: Exim routes the mail,
calls transport filter and uses the output (if filter return success) in order
to execute the pipe command. Were there any special reasons to implement it not
sequentially?

>>and (as a savety measure)
>>will return the original email without any changes. Exim will take that
>>mail and deliver it. *Additionally* the original mail will stay in the
>>queue and the queue runner will try to deliver it on the next run.
>
>
> when will the message ever leave the queue?


After the failure was resolved (maybe database was restarted automatically) or a
human operator investigated the failure.

fs