https://bugs.exim.org/show_bug.cgi?id=2341
Jeremy Harris <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Assignee|[email protected] |[email protected] --- Comment #1 from Jeremy Harris <[email protected]> --- > 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. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
