[exim-dev] [Bug 2341] delay_warning failing to send messages
https://bugs.exim.org/show_bug.cgi?id=2341 --- Comment #4 from Jeremy Harris --- Created attachment 1151 --> https://bugs.exim.org/attachment.cgi?id=1151=edit proposed patch David - are you in a position to test a patch? This, on top of current master, tries to pull from the retry DB to build a warning message on a "retry time not reached". Not all possible causes result in a reasonable error message in the mail (roughly, only errors from actual SMTP conversations do), but all should get a mail generated. -- 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/ ##
[exim-dev] [Bug 2341] delay_warning failing to send messages
https://bugs.exim.org/show_bug.cgi?id=2341 --- Comment #3 from Simon Arlott --- (In reply to Jeremy Harris from comment #2) > Bug -> Wishlist, as current operation is as documented. The current behaviour not documented. The documentation only tells you to run retries more frequently than the warnings should be sent. It doesn't tell you that Exim will not send warnings for each message when there is more than one message in the queue for the same destination. -- 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/ ##
[exim-dev] [Bug 2341] delay_warning failing to send messages
https://bugs.exim.org/show_bug.cgi?id=2341 Jeremy Harris changed: What|Removed |Added Severity|bug |wishlist --- Comment #2 from Jeremy Harris --- Bug -> Wishlist, as current operation is as documented. -- 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/ ##
[exim-dev] [Bug 2341] delay_warning failing to send messages
https://bugs.exim.org/show_bug.cgi?id=2341 Jeremy Harris changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|ni...@exim.org |jgh146...@wizmail.org --- Comment #1 from Jeremy Harris --- > 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/ ##
[exim-dev] [Bug 2341] New: delay_warning failing to send messages
https://bugs.exim.org/show_bug.cgi?id=2341 Bug ID: 2341 Summary: delay_warning failing to send messages Product: Exim Version: 4.91 Hardware: x86 OS: Linux Status: NEW Severity: bug Priority: medium Component: Delivery in general Assignee: ni...@exim.org Reporter: dp...@cam.ac.uk CC: exim-dev@exim.org We have the following parameter set in our configure file: delay_warning = 24h:30d The most common reason for delay_warning messages is if someone runs out of quota on our Cyrus mailstore (lmtp delivery). Email to that domain is queued for up to 14 days: *@hermes.cam.ac.uk * F,5m,1m; F,2h,15m; F,8h,30m; F,7d,60m; F,14d,2h We received a complaint last week when someone received a final bounce message after 9 days (because the final cutoff time had been reached) but no warning after 24 hours. Investigation revealed that there were only three actual delivery attempts to the LMTP server over the course of 9 days: 2018-11-20 13:39:02 + 1gP6F4-000kTG-dC == x...@hermes.cam.ac.uk R=hermes_lmtp T=hermes_lmtp defer (-44) H=cyrus-8a-intramail.csi.cam.ac.uk[192.168.128.8]:2003: SMTP error from remote mail server after RCPT TO:: 452 4.2.2 Over quota SESSIONID= 2018-11-20 15:55:30 + 1gP6F4-000kTG-dC == x...@hermes.cam.ac.uk R=hermes_lmtp T=hermes_lmtp defer (-44) H=cyrus-8a-intramail.csi.cam.ac.uk [192.168.128.8]:2003: SMTP error from remote mail server after RCPT TO:: 452 4.2.2 Over quota SESSIONID= 2018-11-28 21:21:34 + 1gP6F4-000kTG-dC == x...@hermes.cam.ac.uk R=hermes_lmtp T=hermes_lmtp defer (-44) H=cyrus-8a-intramail.csi.cam.ac.uk [192.168.128.8]:2003: SMTP error from remote mail server after RCPT TO:: 452 4.2.2 Over quota SESSIONID= 2018-11-28 21:21:34 + 1gP6F4-000kTG-dC ** x...@hermes.cam.ac.uk: retry timeout exceeded All of the other delivery attempts (many each day) were deferred: 2018-11-21 00:01:30 + 1gP6F4-000kTG-dC == x...@hermes.cam.ac.uk routing defer (-51): retry time not reached It looks like the delay_warning stuff only kicks in when there is an actual delivery attempt. I suspect that it has always been this way and I have simply failed to notice. delay_warning messages work fine when a small number of messages are delayed to a single target account. However when you have 20 or 30 stuck messages for a given target account only a fraction of these messages generate delay_warning messages. It becomes a lottery based on the "retry time not reached" test on each delivery. I don't see an easy fix: presumably the retry database would have be keyed on Exim queue id as well as recipient, and that would probably have all sorts of negative side effects. Presumably a workaround would be to have a dedicated queue runner which forces a delivery attempt a few times a day, ignoring the retry database? Sorry if this is a FAQ: I couldn't find anything after a few minutes of searching. -- 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/ ##
