2

from what I understand exim retries are supposed to be HOST based, NOT message based. This seems to make sense to me; if a host's server is overloaded or otherwise telling you to "delay sending messages", it would seem to be bad form to delay the message that caused it for a few hours, but keep hammering the server with all the other messages destined for that host (i.e. if yahoo says 'stop', you should stop for all yahoo messages! Not just keep trying them and delaying them as the server tells you over and over to STOP!).

From what I've read, this is how Exim is supposed to work, HOWEVER:

My retry rules (for the 'big hosts', aka the ones that hurt the most when they defer or block, we use: every 5 hours for 4 days):

         \N^[^@]+@yahoo.\N     *           F,4d,5h;
         \N^[^@]+@rogers.\N     *           F,4d,5h;
         \N^[^@]+@hotmail.\N     *           F,4d,5h;

Result of checking exinext:

Transport: mx-rogers.mail.am0.yahoodns.net [98.139.214.154/208.83.209.44]:1W1Lmv
-0004iy-IL error -45: SMTP error from remote mail server after MAIL FROM: SIZE=13119: host mx-rogers.mail.am0.yahoodns.net [98.139.214.
154]: 421 4.
  first failed: 09-Jan-2014 15:12:45
  last tried:   09-Jan-2014 15:12:45
  next try at:  09-Jan-2014 20:12:45

Transport: mx-rogers.mail.am0.yahoodns.net [98.139.214.154/208.83.209.44]:1W1M9J
-0007Cj-PV error -45: SMTP error from remote mail server after MAIL FROM: SIZE=13105: host mx-rogers.mail.am0.yahoodns.net [98.139.214.
154]: 451 4.
  first failed: 09-Jan-2014 15:40:17
  last tried:   09-Jan-2014 15:40:17
  next try at:  09-Jan-2014 20:40:17

Transport: mx-rogers.mail.am0.yahoodns.net [98.139.214.154/208.83.209.47]:1W1Lss
-000521-Cf error -45: SMTP error from remote mail server after MAIL FROM: SIZE=13113: host mx-rogers.mail.am0.yahoodns.net [98.139.214.
154]: 421 4.
  first failed: 09-Jan-2014 15:12:06
  last tried:   09-Jan-2014 15:12:06
  next try at:  09-Jan-2014 20:12:06

I picked this example specifically because it shows the same mx server and IP (I recall that can have an impact on the retry rules...). As I understand it, if the 15:12:06 email was the first one to trigger the retry, then the one at 15:40:17 (to same host) shouldn't have been attempted for at least 4 hours. What appears to be happening is that it tries to send the email on the first try REGARDLESS of the rules.

How can we fix this?

Ben A. Hilleli
  • 193
  • 1
  • 7

1 Answers1

2

What I see is how it is supposed to work by design.

A message not part of a 'queue run' (in this case when the message is received) an immediate delivery is attempted.

Once that fails, it will honor the retry times. While you see the 'next try' for each as being different, when it tries to process those messages again it should honor the retry time for the host.

Reference: Exim - Retry Configuration (fourth paragraph from the top)

  • Thanks for pointing it out! We are a bulk sender. A legitimate double-opt in, but alas, lots of mail means we get throttled and sometimes blocked. We've got DKIM, SPF, proper reverse DNS, bounce email removal and yet still hit Yahoo deferrals and blocks. All the best-practice stuff I read says to 'stop sending for a host that is rejecting or throttling you' which is why I thought this was a problem.... Is there a way around this characteristic of Exim? Would it be a good idea? – Ben A. Hilleli Jan 14 '14 at 21:05
  • As was pointed out, it's a REtry rule, not a FIRST try rule. If you want it to not do that immediate send for a host that's tempfailing you, you will first need to do some kind of logging of send failures in your transports to some central location (database, memcache, etc). Then when an inbound message comes in that would be delivered to that destination, instead set it to control=queue. The trickiness will be to figure out what to log, and how to query and determine that $current_inbound_email needs to be queued instead of delivered. – Todd Lyons Jan 14 '14 at 21:54
  • Take a look at the queue_only* directives. It should be fairly straightforward to whip something up using those. [Exim Option Index](http://www.exim.org/exim-html-current/doc/html/spec_html/ch-option_index.html) –  Jan 14 '14 at 21:54