Philip Hazel wrote...
> I found three bugs! Well, two bugs and one infelicity, I guess. This is
> the ChangeLog entry for the fixes:
This is great news for me - you've really made my day. Thank you very
much for looking into the problem so quickly.
> PH/52 Two bugs concerned with error handling when the smtp transport is
> used in LMTP mode:
>
> (i) Exim was not creating retry information for temporary errors
> given for individual recipients after the DATA command when the
> smtp transport was used in LMTP mode. This meant that they could
> be retried too frequently, and not timed out correctly.
I think that probably covers the retry weirdness I'd noticed when testing.
> (ii) Exim was setting the flag that allows error details to be
> returned for LMTP errors on RCPT commands, but not for LMTP errors
> for individual recipients that were returned after the DATA
> command.
That's the main issue we had - woohoo!
> PH/53 This is related to PH/52, but is more general: for any failing
> address, when detailed error information was permitted to be
> returned to the sender, but the error was temporary, then after
> the final timeout, only "retry timeout exceeded" was returned. Now
> it returns the full error as well as "retry timeout exceeded".
That will certainly be helpful for over quota conditions - excellent :)
> I have committed the code for the fixes, so it will be in tonight's
> snapshot.
I will update our production Exim package in the next day or two.
> Incidentally, smtp_return_error_details has nothing to do with this. It
> is concerned with how much error detail to return when rejecting an
> incoming message.
I was confused about that. I don't think I really expected it to make a
difference in the problem I reported but I was trying to be thorough
before reporting it. Above, in PH/53 though, you mention "when detailed
error information was permitted to be returned to the sender" - how is
that information permitted if not by the smtp_return_error_details
setting?
