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: nigel@???
Reporter: dpc22@???
CC: exim-dev@???
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 +0000 1gP6F4-000kTG-dC
== XXX@??? 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:<XXX@???>:
452 4.2.2 Over quota
SESSIONID=<cyrus-8a.csi.private.cam.ac.uk-6287-1542721142-1>
2018-11-20 15:55:30 +0000 1gP6F4-000kTG-dC
== XXX@??? 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:<XXX@???>:
452 4.2.2 Over quota
SESSIONID=<cyrus-8a.csi.private.cam.ac.uk-72761-1542729330-1>
2018-11-28 21:21:34 +0000 1gP6F4-000kTG-dC
== XXX@??? 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:<XXX@???>:
452 4.2.2 Over quota
SESSIONID=<cyrus-8a.csi.private.cam.ac.uk-53904-1543440094-1>
2018-11-28 21:21:34 +0000 1gP6F4-000kTG-dC ** XXX@???: retry
timeout exceeded
All of the other delivery attempts (many each day) were deferred:
2018-11-21 00:01:30 +0000 1gP6F4-000kTG-dC
== XXX@??? 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.
