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" :-) -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
