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
> andrew@???
>
> --
> ## 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
chibi@??? Rakuten Communications
