smtp – Exim Defer (-53): Retry Time Not Reached for Any Host

eximsmtp

I'm an exim newbie – and have inherited a system running exim which is misbehaving.

My instance has stopped sending emails. It is accepting messages into the queue, and is running with -q1h – each hour, for each message in the queue, it reports…

defer (-53): retry time not reached for any host

It is configured to use a highly available smart host – so this is not an issue with the remote MTA. Indeed running exim -v from the command line to send an email it is passed off to the smart relay immediately. i.e. there is no issue with the routing, authentication, availability. Exim is simply not attempting to forward these emails.

I see lots and LOTS of people saying that the way to fix this is to reset the retry database either by deleting just the lockfiles, or the lockfles and retry database. Neither method had any impact on my mailq.

NB this is not a retry after a failure – exim has never attempted to pass on the message.

The retry configuration is as per default:

begin retry
* * F,2h,15m; G16h,1h,1.5; F,4d,6h

I imagine that the -q1h is the reason it does not immediately try to relay the message. But why is it not picking up messages from the queue?

Since this is handing off to a smart relay, I have no need to back up the messages for an hour. If I remove the -q1h from the options, will exim keep scanning the queue regularly or just ignore it?

Best Answer

The-q1h means that the daemon will process the queue once every hour. Having it process the queue is sensible, as even though you are sending via a smarthost, even that can be offline / unreachable for whatever reason, and will cause messages to be placed in the queue. Not running the queue would mean those messages are never sent.

The fact that exim is reporting "retry time not reached for any host" means that the smarthost apparently was unreachable at some point. To prevent wasting resources repeatedly trying to access an offline host, a retry time is imposed, and that time has apparently not yet been reached. I'm sure that if you search the logs further you will see where the smarthost was unreachable.

You can force an attempt to deliver a message by running exim -M messageID (you can see the message IDs with exim -bp or mailq if exim has been linked to this name).

Related Solutions

Exim: remote host is local host

Exim doesn't, by default, let you send mail back to yourself. You can change this behavior by using the self router option. Here's an example from my config in which I had to use self = send to get Exim to send "slow" mail to another instance on the same host:

stalemail:
  driver = manualroute
  condition = ${if > {$message_age}{900}{yes}{no}}
  self = send
  domains = ! +local_domains
  route_list = * mailhub-01.example.com::8025:mailhub-02.example.com::8025
  transport = remote_smtp

Exim4 smarthost with sender verification

In effect, you're setting up a front-end MX with a more restrictive set of filters deeper towards the final destination. The best way to tackle this is to be at least as restrictive at the front-end.

Because you have a smarthost though, you send email for "any domain" out to the smarthost. This combines badly with domain validity checking: somewhere in your ACL defined for RCPT commands, there should be a require verify = sender which ensures that Exim has a method for sending email to the sender domain before it will accept the message.

Since you're always-on, I recommend putting an extra Router directly before your smarthost Router. Assuming that the smarthost has domains = ! +local_domains and no_more, then add no_verify to the smarthost Router and before it, insert this Router:

remote_dns_verify:
  driver = dnslookup
  domains = ! +local_domains
  transport = remote_smtp
  # ignore_target_hosts = +some_hostlist_matching_rfc1918_and_so_on
  same_domain_copy_routing
  verify_only
  no_more

With this, the verification path will not use the smarthost, so you will no longer have "a route for everything". The verification will only be able to route remote domains which have DNS, so you'll no longer accept emails which your ISP is rejecting for being unrouteable.

After that, I'd look into setting some retry rules which match specific remote errors to stop retrying mails which the ISP has rejected. See http://www.exim.org/exim-html-current/doc/html/spec_html/ch-retry_configuration.html for more.

Best Answer

Related Solutions

Exim: remote host is local host

Exim4 smarthost with sender verification

Related Topic