On Fri, 18 Feb 2022 10:58:35 +0000 (GMT) Andrew C Aitchison via Exim-users wrote:
> On Fri, 18 Feb 2022, Christian Balzer via Exim-users wrote: > > On Thu, 17 Feb 2022 11:25:01 +0000 Jeremy Harris via Exim-users wrote: > >> On 17/02/2022 05:04, Christian Balzer via Exim-users wrote: > >>> Maybe phrasing here, but clearly the previous behavior of displaying the > >>> full response of the remote SMTP server is more "beautiful" than the > >>> truncated to the point of unreadable one with current Exim versions? > >> > >> Oh, you are comparing to a previous Exim version. I suggest you > >> log a bug, giving details of the versions, and any difference > >> in the configs used. It would also help to know what the state > >> of the retry DB is for the problem address prior to the delivery > >> attempt that results in a problem bounce message. > > > > Well, after re-jiggering my ancient bugzilla account I found it was > > already reported in all its glory, 2 years ago. > > You weren't kidding when you said a fix would not be quick, but this is > > still a major regression in my book... > > > > https://bugs.exim.org/show_bug.cgi?id=2535 > > As I read that bug, this does not appear to be a regression. > When the time comes to report that a message is still waiting in the > queue, if an attempt to send the message fails exim reports the full > message, but if no attempt is made *at that time, exim reports the > truncated message stored from the latest attempt. > Thanks so much for that input, that was the proverbial missing link. As it turns out that truncated report did indeed result from a queue run without any delivery attempts. However I can't recall ever seeing a truncated warning with the old 4.89 based systems with exactly the same retry settings and queue-runner intervals. Somehow I doubt having been that lucky all those years, though admittedly my sample size is not that huge, given that "errors_copy" does not include these warnings. Another forced attempt just now also resulted in a truncated version. Ignoring the hints DB for a moment, with a queue run every 2 minutes and a retry interval of 1 minute, a queued mail should be eligible for a retry and always create a full report, or are there more corner cases? > As an alternative to changing DB, a possible fix would be to have an > option so that delay warnings only happen when a retry fails. > Good call as well, seems like a least resistance/complex approach. Regards, Christian > -- > Andrew C. Aitchison Kendal, UK > [email protected] > > -- > ## List details at https://lists.exim.org/mailman/listinfo/exim-users > ## Exim details at http://www.exim.org/ > ## Please use the Wiki with this list - http://wiki.exim.org/ > -- Christian Balzer Network/Systems Engineer [email protected] Rakuten Communications -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
