Philip Hazel wrote:
> This is the ChangeLog entry to which I was referring:
>
> PH/45 In a pipe transport, although a timeout while waiting for the pipe
> process to complete was treated as a delivery failure, a timeout while
> writing the message to the pipe was logged, but erroneously treated as a
> successful delivery. Such timeouts include transport filter timeouts. For
> consistency with the overall process timeout, these timeouts are now
> treated as errors, giving rise to delivery failures by default. However,
> there is now a new Boolean option for the pipe transport called
> timeout_defer, which, if set TRUE, converts the failures into defers for
> both kinds of timeout. A transport filter timeout is now identified in
> the log output.
I don't think that the behavior I'm seeing is related to this as the
filter process does not time out. Instead it exits with an error code
after 1-2 seconds.
If you think that this behavior may be fixed in 4.60, I will test my
configuration with the latest version of Exim.
fs
