Re: [exim] fatal errors in BSMTP transport

Hi,

Marco Herrn wrote:
> On Fri, Feb 10, 2006 at 01:11:47PM +0100, Paul Dekkers wrote:
>
>>> But what is still confusing me, is that the mail don't get delivered.
>>> When spamc gets a timeout, that should be a 4xx error (which is the
>>> case). But why does the message bounce?
>>>
>> ... good question :-)
>>
>> (Hmm, the exim -bS created the 4xx error, but the pipe / transport was a fatal error, I believe?)
>>
>
> Of course! Since the mail is already accepted, the mailserver cannot
> reject the mail, but instead has to bounce it.
>

(by this reject you mean defer, I think ;-))

> Would be nice, if exim itself could try to redeliver the mail through
> the transport after such errors. Is that possible in any way?
>

(Not that I know of, but:) in that regard I wonder if it would make
sense if the transport filter was called before the real pipe (or other
transport mech.) was actually used... That way you can handle errors and
timeouts from both in a clean(er) way maybe? (And that is somehow what
spamc -e does...)

Regarding the:
"Note that there is a very slight chance mail will be lost here, because
if the fork-and-exec fails there's no place to put the mail message."
I wonder if this is true with exim, since I assume spamc will die with a
non-zero return value, and exim will notice and keep the message? (Maybe
we can simulate this exec-fail, hmm.)

I did not notice this warning btw, because I discovered this option with
spamc --help instead ;-)

Paul

P.S. I gave up trying to reproduce the problem; I'm sure it will return
if I put my statefull firewall inspection back in on our production
server, but well... ;-) it does not happen in my "lab enviroment" :-)