https://bugs.exim.org/show_bug.cgi?id=2408
--- Comment #9 from David Carter <[email protected]> --- 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. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
