Take the 2-minute tour ×

I have one sendmail host exposed to the outside world accepting mail for a variety of domains, which relays mail it receives for those domains to the domain's corresponding internal server (by way of mailertable). Most internal servers have excellent uptimes but occasionally there is a hiccup and a server may be unreachable. In such a scenario, sendmail attempts to forward the mail to a downed server but is unable to do so, and logs a 5.0.0 Service Unavailable error (and issues a 5.0.0 DSN back to the sender).

Obviously, this is not good for a production environment as inbound emails will be forever lost in the above scenario. How can I instruct sendmail to queue the messages and keep retrying, and if it cannot deliver them after a week, remove them from the queue and issue the failure DSN?

share|improve this question
I have no experience with Sendmail, but a normal mail server should queue failed mails and try again later. So this should be possible; let's see what others say. –  Peter Eisentraut Jan 12 '10 at 10:23
add comment

1 Answer

up vote 1 down vote accepted

Tweaking sendmail configuration options

Sendmail cf/README

Check out options such as confTO_QUEUERETURN and confTO_QUEUEWARN

You should think carefully before you change this parameter to queue mail for many days on your SMTP gateway. The reason the mails are returned after several hours of non-delivery is to let the sender know that the mail could not be sent. Technically the emails are not lost, as the sender is notified of the failure.

share|improve this answer
The problem is not that the mails are returned after several hours; they are returned immediately and removed from the queue and delivery is never re-attempted later. Also, of course I understand there's technically a difference between sending someone a message that isn't delivered and getting a DSN back, versus the mail simply never being delivered, but realistically speaking the mail is lost as far as the recipient is concerned if it never gets to them. –  Brian Cline Jan 12 '10 at 16:26
That being said, thanks for the suggestion, however tweaking those does not solve the problem. After tweaking those, it queues the messages for delivery through the smarthost defined in the configuration file, which comes straight back to the same SMTP gateway. This seems to be an issue with messages that cannot be delivered via mailertable. –  Brian Cline Jan 12 '10 at 16:51
Disregard that; I failed to mention in my original post that I was using a fallback smarthost. After changing it from a fallback to a normal smarthost in the configuration, messages are successfully queued then delivered after the next hop server comes back online. –  Brian Cline Jan 12 '10 at 17:10
add comment

Your Answer


