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 +0000 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:<x...@hermes.cam.ac.uk>:
     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
  == 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:<x...@hermes.cam.ac.uk>:
    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
  == 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:<x...@hermes.cam.ac.uk>:
  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 ** 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 +0000 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/ ##

Reply via email to