I have a slow distant mail relay server and a web application I'm using locks up when sending e-mails to that distant mail server, until the e-mail is sent. After the e-mail is sent the page comes back and the application is snappy again.

So I'm trying to set up a differed mail queue locally on the application server (Linux) so that the application uses that instead of the distant mail server. My rationale is that e-mails would get queued up locally until they are processed by the distant mail server, but at least the application doesn't lock up.

I have installed postfix and set up the relayhost setting to the distant mail server, but performance has not improved. What appears to happen is that postfix just forwards my SMTP instructions in real time and doesn't really queue them?

What can I do?

migrated from superuser.com Jun 25 '11 at 12:18

This question came from our site for computer enthusiasts and power users.


The problem doesn't lie in Postfix. Before you had Postfix installed, your application was directly submitting your mail to a distant SMTP Submission server, out across Internet. The step that you've missed is reconfiguring your application. It's still going out to the distant server. You need to tell your application, perhaps indirectly, to submit mail locally.

If it is a PHP application, for example, then the behaviour of the mail() function is controlled by the sendmail_path configuration option on Unices and Linux. It's probably currently pointing to a shim program that just cranks up a SMTP Submission connection and pumps its standard input across it. You need to point this to the Postfix submission program, sendmail, instead.

This is probably not living at /usr/bin/sendmail because your shim program is there, and is likely to be found at /usr/bin/sendmail.postfix or somewhere similar instead. Indeed, if you have the "alternatives" system /usr/bin/sendmail will be a symbolic link to /etc/alternatives/mta-sendmail, itself a symbolic link, and you may have to re-target the latter.

By whatever means, which involves details of your distribution, application, and configuration that we cannot telepathically divine, you need to get your application invoking the right program. Simply installing Postfix didn't do that part.

Note that Postfix is in the same camp as Zmailer, MMDF, and qmail. What BillThor writes in another answer here is a complete red herring based upon Sendmail Think. Sendmail and exim are humungous monolithic programs that have to have distinctions between "fast and non-queued" and "slow and queued" modes because of the way that they are architected. Either the submission program morphs into a transport agent, and doesn't exit until it has canonicalized, routed, and transmitted (or attempted to) the message, which will be a long time in your case; or the submission program always dumps mail into a queue, where it waits until a queue runner process wakes up, delaying it by however long the queue runner's polling interval (usually on the order of minutes or hours) is.

Postfix and qmail follow in the footsteps of MMDF, with multiple small separate programs doing one job each, in accordance with the Unix philosophy. Mail is always deposited into a queue. But the queue injection program (postdrop in the case of Postfix) triggers a semaphore of some sort (It's a named pipe in qmail.) to wake up the queue processing daemon (a preprocessing daemon, pickup, in Postfix's case) immediately. To borrow and slightly modify a quote from Dan Bernstein:

Other MTAs offer a spectrum of delivery modes, from fast+unsafe to slow+queued. The queue daemons in qmail and Postfix are instantly triggered by new items in the queue, so the system has just one delivery mode: fast+queued.

This is exactly what you want. You want the sendmail program to terminate quickly, enabling your application (which is waiting for it to terminate) to continue, and the queue processing to start immediately, but in parallel. Postfix, qmail, nullmailer, and the like will all give you this. You just need to fix your application to invoke the correct submission agent.

  • Sorry for not answering earlier but I ended up finding a different way and it got me going. Then I forgot to report back. About your first paragraph dealing with not changing the application configuration: this is the second thing I did after I installed postfix, I pointed the app to localhost. So when I realized postfix wasn't cutting it I tried qmail to no avail. It was still slow as hell. I bypassed the issue entirely by finding a module for the app that takes care of the queueing directly in the app. I would have a liked a generic solution but in my job I have more issues than time. – md1337 Jul 22 '11 at 20:24

You want to set up postfix to defer mail delivery:

defer_transports = smtp
disable_dns_lookups = yes

in your main.cf.

You can then flush the queue with sendmail -q when you wish to deliver.

Have a look at Postfix Backup MX configuration

Hope this helps.

  • 1
    Doesn't answer the question asked. The questioner wants initial mail submission by the application program to complete quickly. Manually scheduling the transports is a red herring. – JdeBP Jun 25 '11 at 8:37

Mail servers usually prefer to deliver messages immediately rather than queue them up for later delivery. It has been my experience that many email users expect this Instant delivery mode.

I looked for instruction for running Postfix in queue-only mode, but didn't find any. Exim which is packaged for many distibutions can be configured to run in queue-only mode. New messages will be queued and delivered later by a queue-runner process. This is likely what you want. Exim is normally configured to do minimal checks on messages received from local sources.

Alternatively, you could look at spawning a thread or process to sent the email.

  • Doesn't answer the question asked, because it appears to be based upon some entirely bogus idea that every MTS has the huge monolithic program architecture of Sendmail. Even just reading the Postfix architecture diagrams in the Postfix documentation would have disabused one of that erroneous idea. – JdeBP Jun 25 '11 at 8:40
  • @JdeBP: I did referred to the Postfix documentation and I am well aware of the architecture. While postfix uses separate processes to do the various steps, the overall processing is the same. As noted, I wasn't able to readily discover any flags to control queueing. As another answer notes, it is available. – BillThor Jun 26 '11 at 2:18
  • 1
    You very clearly are not aware of the architecture if you went looking for a queue-only mode and recommended exim on the basis of not finding the Postfix documentation talking of an option that isn't at all necessary with the Postfix architecture and is only necessary with monolithic softwares like exim and Sendmail. You very clearly are not aware of the architecture by your statement here that quadruplebucky's configuration options relate to queue injection. They do not. You applied Sendmail Think and were wrong. – JdeBP Jun 26 '11 at 13:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.