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.