https://bugs.exim.org/show_bug.cgi?id=2341
Jeremy Harris <jgh146exb@???> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|nigel@??? |jgh146exb@???
--- Comment #1 from Jeremy Harris <jgh146exb@???> ---
> It looks like the delay_warning stuff only kicks in when there is an actual delivery attempt
Yup. The docs say:
Note that the option is only evaluated at the time a delivery attempt fails,
which depends on retry and queue-runner configuration. Typically retries will
be configured more frequently than warning messages.
I don't think your suggested workaround would do anything but get another
"retry time not reached" for most of the attempts.
Possibly you could divert old messages to an alternate queue using the
EXPERIMENTAL_QUEUEFILE facility, and hack something with that - maybe an
alternate config for the queue-runner for that - but "hack" really is the word.
I'll have a look at the possibility of hooking the "retry time not reached"
path to the warning message generator. It looks like the latter keeps a count
of messages sent in the message spool file, presumably modifying it when one
is sent - and compares that with a "how many should have been sent by now"
evaluation. This should be safe against being called more often, at the
cost of extra processing; the cost would then relate to the queue-runner repeat
rate rather than the retry-rule applying to the relevant message.
Perhaps it should be configurable as to which domains this is applied.
--
You are receiving this mail because:
You are on the CC list for the bug.
