[exim] Re: Errors in transport filters

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Felix Schwarz
Datum:  
To: exim-users
Betreff: [exim] Re: Errors in transport filters
Philip Hazel wrote:
> On Thu, 8 Dec 2005, 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.
>>
>>What Exim does is: It takes the mail, calls the transport filter script. This
>>script will return a non-zero exit code 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.
>
>
> That seems to be exactly in accordance with Exim's specification. A
> non-zero return from a transport filter is a failure; Exim thinks the
> delivery has failed, so it tries again later. It cannot tell that what
> appears to it to be an entirely different message that has been
> submitted is in fact the same message again. You can't be "returning"
> the original mail. There's no way to do that. You are submitting another
> message.


Sorry for my wording. I used the phrase "original mail" in two different
meanings. Your description matches exactly what I want to achive. After the
transport filter failed the message should stay in the queue. I only want to
eliminate the "extra mail" which is made of the output of the failed transport
filter..

> Transport filters are not supposed to fail.


That is maybe the key sentence but I did not find this in your book although I
thought that I read the pages 161-164 quite carefully. One thing is (as you
mentioned in another posting) that I was not aware that a Un*x filter is
executed in parallel.

> The script could perhaps buffer the message in
> memory, and then either write it all out and return zero, or write out
> nothing (so no message is submitted) and return non-zero (so Exim tries
> again later).


The thing is that Exim will send a mail every time independent from the exit
code returned by the transport filter. If the exit code is non-zero, the mail
will stay in the queue additionally. But Exim will send a mail even if there was
no output at all. In this case the body of the mail sent will be empty.

As I see it there is currently no possibility that the transport filter can fail
without sending an additional mail as the new exim instance will be invoked at
the same time (in parallel) to the transport filter script and this new instance
does not know anything about the transport filter, exit codes etc.

fs