Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm writing an email notification system that needs to send many hundreds of emails at once. The system needs to be deployed on various setups with different MTAs. Depending on the configuration, some MTAs seem to receive an email from an application and queue it as fast as possible; others will hold the sender application while processing (sending?) the message – this would cause the application to block for extended periods of time.

Would it be reasonable to expect MTAs on production machines with modern software to queue mail quickly (or be configured to do so)?

share|improve this question

Unfortunately, it depends. If you need to work with a variety of different MTAs, then you're going to have to do things like load average detection (if the load average rises above a certain number, then throttle delivery), and probably also do your own domain aggregation to reduce the number of delivery attempts required.

share|improve this answer
I'd leave all that to the MTA. My concern is the sender application: I don't want it to block waiting for the MTA to do delivery, but rather the MTA should queue for later delivery. – Alex Morega Aug 4 '09 at 10:41
You can't guarantee that the MTA will do that (or any other vaguely sane thing) if you can't rely on having a particular implementation running. There's a lot of stupid MTAs out there -- far, far stupider than you can possibly imagine. – womble Aug 4 '09 at 22:28

If you ever go above a few hundred at any given moment, something like will handle this really well for you. It has DNS caching and can control how many connections it makes to a remote server, both of these are key to getting emails to their recipients properly. I've managed 320K / hour on a 5 year old server with this piece of software.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.