On Wed, 1 Mar 2006, I wrote:
> I'm starting to look at this. The first thing that occurs to me is that
> 4XX is a temporary error which will not of itself cause the message to
> be returned. The return will not happen until the retry time is
> exceeded. Of course, you can set the retry time to zero, but logically
> that's how Exim handles it. So I would have expected the message to be
> "retry time exceeded" if anything. Can you confirm whether or not you
> see that in your log? I will peer at the code and see if the 4XX error
> message is still preserved, and then see if anything can be done.
I found three bugs! Well, two bugs and one infelicity, I guess. This is
the ChangeLog entry for the fixes:
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.
(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.
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".
I have committed the code for the fixes, so it will be in tonight's
snapshot.
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.
Philip
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
