1998: Postfix: The Friendly Alternative That Dethroned Sendmail
In December 1998, a Dutch programmer working at IBM’s Thomas J. Watson Research Center in Hawthorne, New York released a piece of software that would quietly reshape the internet’s email infrastructure over the following decade. His name was Wietse Venema, and the software — after a brief identity crisis involving the names “VMailer” and “IBM Secure Mailer” — became known as Postfix.
Where sendmail was powerful but terrifyingly complex, and qmail was secure but dogmatically austere, Postfix aimed for something that neither predecessor had achieved: being genuinely good at everything that mattered without making administrators suffer for it.
The IBM Connection
Venema was already well-known in the security community before Postfix. He had co-authored TCP Wrapper (tcpd), one of the first widely deployed network access control tools, and co-developed SATAN (Security Administrator Tool for Analyzing Networks), a network vulnerability scanner that caused a media panic when it was released in 1995. Security was in his DNA.
His position at IBM Research gave him the time and resources to tackle a large-scale systems project. IBM, for its part, got the public relations benefit of sponsoring a significant open-source security project during a period when the company was actively rebuilding its relationship with the open-source community. The arrangement worked well for both parties.
Venema’s motivation was straightforward. Sendmail had a terrible security track record and a configuration system that bordered on hostile. qmail was secure but its licensing prevented proper distribution, and its minimalist approach required administrators to bolt on numerous third-party tools for basic functionality. There was a clear opening for an MTA that combined sendmail’s comprehensive feature set with qmail-inspired security architecture and human-readable configuration.
The Design Philosophy
Postfix’s architecture reflected lessons learned from both its predecessors. Like qmail, it used a modular design with privilege separation — different processes handled different functions (receiving mail, queue management, delivery), each running with minimal permissions. But unlike qmail, Postfix didn’t force administrators to abandon familiar paradigms.
The configuration file, main.cf, was a revelation for anyone who had wrestled with sendmail.cf. Parameters were named in plain English: myhostname, mydomain, mynetworks, relay_domains. Comments were written in complete sentences. The default configuration worked out of the box for simple setups, and modifications for common scenarios could be made by changing obvious parameters.
Here’s the contrast. In sendmail, configuring a relay host looked something like:
define(`SMART_HOST', `smtp.relay.example.com')
In Postfix:
relayhost = smtp.relay.example.com
The difference seems trivial in isolation, but multiplied across hundreds of configuration options, it was transformative. System administrators who had spent hours deciphering sendmail’s m4 macros could accomplish the same tasks in Postfix in minutes. The learning curve wasn’t just flattened — it was practically eliminated for common configurations.
Modular Architecture
Postfix’s internal architecture divided responsibility among about a dozen semi-independent programs, each responsible for a specific function:
smtpd handled incoming SMTP connections. pickup watched the maildrop directory for locally submitted messages. cleanup processed incoming messages, adding missing headers and performing address rewriting. trivial-rewrite handled address rewriting (with dramatically less complexity than sendmail’s rule sets). qmgr managed the mail queue. smtp handled outbound delivery to remote servers. local delivered to local mailboxes. pipe delivered through external commands. bounce handled bounce messages.
Each program ran as an independent process with carefully limited privileges. They communicated through well-defined interfaces — mainly the filesystem and Unix sockets. If a vulnerability was found in smtpd (the component most exposed to the internet), the attacker would only compromise the unprivileged smtpd process, not the queue manager or the delivery agents.
This architecture also made Postfix remarkably resilient. If one component crashed, the others continued functioning. The queue manager could be restarted without losing messages. Individual delivery agents could fail without affecting other deliveries. The system degraded gracefully under load or in the presence of errors, a characteristic that endeared it to administrators managing high-volume mail systems.
The Sendmail Compatibility Layer
Venema made a pragmatic decision that significantly aided adoption: Postfix included a sendmail compatibility interface. The sendmail command-line interface — used by countless scripts, applications, and web frameworks to submit email — worked identically whether the underlying MTA was actually sendmail or Postfix. Programs that called /usr/sbin/sendmail to send email didn’t need to be modified.
This compatibility layer meant that migrating from sendmail to Postfix didn’t require touching application code. Administrators could swap the MTA, update the configuration, and everything that depended on the sendmail command-line interface continued working unchanged. It was a migration path that dramatically reduced risk and effort.
The Ascent
Postfix’s rise was steady rather than explosive. Early adoption was driven by security-conscious administrators who wanted sendmail’s functionality without its vulnerability profile. University computing departments and research institutions — communities that valued both the open-source nature and the security architecture — were among the first to migrate.
The turning point came when Linux distributions began including Postfix in their default repositories. Unlike qmail, whose restrictive licensing prevented distribution packaging, Postfix was released under the IBM Public License (later relicensed to the Eclipse Public License), which was fully compatible with distribution packaging requirements. Installing Postfix on Debian or Ubuntu was as simple as apt-get install postfix.
Apple’s adoption was another significant milestone. Starting with Mac OS X, Apple chose Postfix as the default MTA on its desktop and server operating systems. Every Mac sold came with Postfix installed. Every macOS Server deployment used Postfix for email. Apple’s endorsement signaled that Postfix was ready for mainstream use, not just niche Unix deployments.
Ubuntu’s selection of Postfix as its default MTA further cemented its position. As Ubuntu grew to become the dominant Linux distribution for servers, particularly in cloud environments, Postfix became the default mail server on millions of new deployments.
Security Record
Postfix’s security track record has been excellent, though not quite as pristine as Bernstein claimed for qmail. Over more than 25 years of widespread deployment, Postfix has had very few security vulnerabilities, and the ones that have been found have generally been minor — typically requiring unusual configurations to exploit. No remotely exploitable root compromise has ever been demonstrated against a properly configured Postfix installation.
This record validates the architectural approach: modular design, privilege separation, minimal trust between components, and conservative handling of untrusted input. Venema applied the same security principles as Bernstein but with a more pragmatic implementation that included better error handling, more defensive coding, and a willingness to address edge cases that Bernstein might have dismissed as non-issues.
Performance and Scale
Postfix was designed for performance from the beginning. The queue management system was optimized for high throughput, and the modular architecture allowed parallel processing of different stages of mail delivery. On the same hardware, Postfix typically outperformed sendmail significantly, particularly under heavy load.
Large-scale deployments proved the performance claims. Internet service providers, web hosting companies, and cloud platforms ran Postfix on servers handling millions of messages per day. The combination of performance, security, and manageability made it particularly popular for transactional email infrastructure — the automated messages (receipts, notifications, password resets) that modern web applications depend on.
Amazon’s Simple Email Service (SES), one of the largest email sending platforms in the world, was built on Postfix. This is perhaps the ultimate performance validation: when Amazon needed to build infrastructure for sending billions of emails, they chose Postfix as the foundation.
Ongoing Development
Unlike some open-source projects that reach a stable state and stagnate, Postfix has continued to evolve. Venema has maintained active development for over 25 years, adapting the software to changes in the email ecosystem. Modern Postfix versions include native support for SPF, DKIM, and DMARC authentication, TLS encryption, IPv6, and integration with policy and content filtering services.
The development process itself reflects Venema’s engineering discipline. Releases are thoroughly tested. Breaking changes are rare and well-documented. The code base is clean and well-commented. For administrators who value stability and predictability — which is to say, virtually all administrators responsible for production email systems — this consistency has been invaluable.
Market Position Today
Postfix and Exim trade the top position in MTA market share surveys, depending on what’s being measured. Postfix tends to dominate in cloud server deployments, corporate infrastructure, and environments where administrators explicitly choose their MTA. Exim leads in web hosting, where its bundling with cPanel gives it an enormous installed base.
Together, Postfix and Exim handle the vast majority of email that still flows through traditional MTA infrastructure. Sendmail has faded to a small fraction of its former market share. qmail exists as a legacy presence. Cloud email services (Gmail, Outlook, Amazon SES) handle an increasingly large share of total email volume but run their own proprietary infrastructure.
The Venema Contribution
Wietse Venema set out to build a better sendmail. What he actually built was the template for how modern internet infrastructure software should work: secure by design, configurable by humans, compatible with existing ecosystems, and maintained with discipline over decades.
Postfix didn’t achieve dominance through marketing or corporate backing (IBM’s involvement was relatively hands-off). It achieved dominance by being genuinely excellent at the things that matter most to the people who run email infrastructure. In a world where software projects rise and fall on hype cycles, that’s a refreshingly old-fashioned accomplishment.
For anyone currently running email infrastructure, we cover the practical differences between today’s leading MTAs in our overview of The Great MTA Wars.
Infographic
Share this visual summary. Right-click to save.
Related Events
Frequently Asked Questions
What is Postfix?
Postfix is a free, open-source mail transfer agent (MTA) created by Wietse Venema at IBM Research in 1998. It was designed as a secure, easy-to-configure alternative to sendmail and has become one of the most widely used MTAs in the world, serving as the default on macOS and Ubuntu Linux.
Is Postfix more secure than sendmail?
Yes. Postfix was designed from the ground up with security as a primary goal, using a modular architecture with privilege separation. Each component runs with minimal permissions, limiting the damage from any potential vulnerability. Its security track record is dramatically better than sendmail's.
What is the difference between Postfix and Exim?
Both are popular open-source MTAs, but they differ in philosophy. Postfix emphasizes security and simplicity with a modular architecture and straightforward configuration. Exim offers maximum flexibility with its own ACL language and a more monolithic design. Postfix is popular on cloud servers and macOS; Exim dominates web hosting through cPanel.
Stay ahead of the inbox
Weekly tips on deliverability, automation, and growing your list. No spam, ever.
No spam. Unsubscribe any time. We respect your inbox.