On Sat, 19 Feb 2022, Christian Balzer via Exim-users wrote:
> 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?
I don't know of any more corner cases, but IIRC retry timestamps are
stored for each domain (or server?) unless a per address timeout is set;
the last attempt time is not stored not per message, so I could not rule
out another message stopping a full report from occurring.
A retry interval of 1 minute will fall foul of grey-listing on some
servers and might be seen as invasive. The default is every 15 mins for
two hours, then increasing intervals until 16 hours, finishing with a
retry every six hours, given up after four days.
15m or 30m is more more usual queue runner interval.
A retry interval of 15min and a queue run every 30min would be more
reaonable, though might not entirely stop truncated reports.
>> 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@???
