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
and...@aitchison.me.uk
--
## 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/
