https://bugs.exim.org/show_bug.cgi?id=2408
--- Comment #9 from David Carter <dpc22@???> ---
This problem is recurring, so I took some time to look at what had changed
between 4.91 and 4.92[.1]. I'm pretty sure that the problem is the following in
src/deliver.c:
/* For remote-retry errors (here and just above) that we've not yet
hit the rery time, use the error recorded in the retry database
as info in the warning message. This lets us send a message even
when we're not failing on a fresh attempt. We assume that this
info is not sensitive. */
addr->message = domain_retry_record
? domain_retry_record->text : address_retry_record->text;
setflag(addr, af_pass_message);
which was added as part of commit de6f74f297d040a34746bc8e1829ad4b867441c9, in
response to a bug that I reported last year.
If I build a test version of Exim 4.92.1 with the text above commented out then
I see a generic delay warning message without the incorrect "Delay reason:"
text.
Further testing reveals that I only see the spurious errors if I have two
separate stuck messages involving a given target domain which are processed in
a single queue run.
It look like domain_retry_record->text from the first message is used in the
error for the second even if the failures are actually unrelated.
The specific example here is where the first address expands to something that
has a missing entry in the DNS while the second expands to an account which has
run out of quota.
If I explicitly force a delivery on the second message using "exim -M" then the
delay_warning messages is correct and includes a "Delay reason: " section which
correctly identifies the quota problem.
--
You are receiving this mail because:
You are on the CC list for the bug.
