1983: Sendmail: The Mail Server That Built the Internet
Before Gmail, before Hotmail, before most people had ever heard the word “email,” a single piece of software was quietly routing the vast majority of the internet’s electronic messages. That software was sendmail, and for nearly two decades, it was the backbone of global email infrastructure. Its story is one of brilliant engineering, legendary complexity, painful security lessons, and an eventual decline that tells us a lot about how internet infrastructure evolves.
The Berkeley Origins
Eric Allman was a graduate student and staff programmer at the University of California, Berkeley when he wrote the first version of sendmail in 1981-1983. The early internet was a mess of incompatible mail systems. ARPANET had its own protocols. UUCP networks — the Unix-to-Unix Copy Protocol connections that linked most Unix machines — used a completely different addressing scheme. Bitnet had another. And these networks all needed to exchange mail with each other.
Allman’s insight was to build a mail router — a program that could accept mail from any of these systems, figure out which network the recipient was on, and translate the message into the appropriate format for delivery. He didn’t invent email or even the SMTP protocol that would become the standard. What he built was the universal translator that could bridge the gap between incompatible systems.
The first version shipped as part of 4.1c BSD (Berkeley Software Distribution) in 1983. Since BSD was freely available to universities and research institutions, sendmail spread rapidly through the academic and research communities that formed the early internet. By the time the internet began its explosive commercial growth in the early 1990s, sendmail was already the established, default mail transfer agent on most Unix systems.
Dominance
The numbers were staggering. Through the mid-to-late 1990s, sendmail handled an estimated 70-80% of all email on the internet. Let that sink in. At the height of the email revolution — when email was transforming business communication, when “You’ve Got Mail” was a cultural phenomenon — one piece of software, written by one person at a university, was routing the overwhelming majority of it.
Several factors drove this dominance. BSD Unix was the foundation of most internet servers, and sendmail came bundled with it. System administrators who set up mail servers simply used what was already there. The alternatives were few and immature. And sendmail, for all its complexity, actually worked. It could handle the messy reality of a heterogeneous internet where different networks used different protocols and addressing conventions.
The Configuration Nightmare
If sendmail had a reputation for anything, it was the near-impenetrable complexity of its configuration. The primary configuration file, sendmail.cf, became legendary in systems administration circles as one of the most difficult files in computing to understand, let alone modify.
The problem was the macro language. Sendmail’s configuration used single-character operators, cryptic rewriting rules, and a syntax that bore no resemblance to any programming language most administrators had encountered. A typical rewriting rule might look like:
R$+@$+ $@$>96 $1@$2
To an uninitiated reader — which included most humans — this was indistinguishable from line noise. The rules processed email addresses through a series of transformations, handling the address rewriting needed to route mail between different systems. Each rule matched a pattern, performed a transformation, and passed the result to the next rule or a specific ruleset. The logic was powerful but expressed in a notation that seemed designed to be hostile.
The famous O’Reilly “bat book” (officially titled “sendmail,” by Bryan Costales and Eric Allman) ran to over 1,300 pages in its later editions. An entire book, larger than most novels, dedicated to configuring a single program. The m4 macro preprocessor was eventually introduced to generate sendmail.cf files from more readable templates, but even the m4 macros required significant expertise.
This complexity wasn’t arbitrary sadism. Sendmail had to handle an enormous range of edge cases — different addressing formats, protocol translations, routing decisions, header rewriting, alias expansion, and more. The configuration language reflected the genuine complexity of the problem. But it meant that a relatively small priesthood of sendmail experts held disproportionate power in the internet infrastructure world.
The Security Catastrophe
Sendmail’s security record was, to put it diplomatically, poor. The program ran with root privileges on internet-facing servers, processed complex input from untrusted sources, and was written in C — a language that provides minimal protection against buffer overflows and other memory-safety vulnerabilities. It was, in retrospect, a perfect target.
The most famous early exploit came in November 1988, when Robert Tappen Morris Jr. launched what became known as the Morris Worm — one of the first major internet worms. Among its propagation methods, the worm exploited a debug mode in sendmail that allowed remote command execution. The worm infected approximately 6,000 machines, which represented roughly 10% of the internet at the time.
The Morris Worm was a wake-up call, but sendmail’s security problems continued for years. The 1990s and early 2000s saw a steady stream of CERT advisories for sendmail vulnerabilities: buffer overflows, format string bugs, race conditions. Each vulnerability potentially affected the majority of the internet’s mail infrastructure, since sendmail’s market dominance meant that a single exploit could compromise an enormous number of servers.
These security issues became a primary motivation for the creation of competing MTAs. Dan Bernstein built qmail specifically because he was appalled by sendmail’s security record. Wietse Venema created Postfix with a security-first architecture at IBM Research. Both projects were, in significant part, responses to sendmail’s demonstrated inability to keep attackers out.
The Commercial Turn
In 1998, Allman co-founded Sendmail, Inc. to commercialize the software. The company offered a commercial version with management tools, support contracts, and enterprise features alongside the open-source version. This was the era when many open-source projects were exploring commercial models — Red Hat, MySQL AB, and others were proving that open-source software could sustain real businesses.
Sendmail, Inc. secured venture capital funding and built a real company with enterprise customers. The commercial product added features that large organizations needed: centralized management, compliance tools, and outbound mail security. For a time, the business was viable.
But the commercial venture coincided with sendmail’s declining market share. System administrators who were already migrating to Postfix or Exim had little reason to pay for a commercial version of the software they were leaving behind. The company was eventually acquired by Proofpoint in 2013 — itself an ironic endpoint, as Proofpoint represented the new generation of cloud-based email security that had grown up around the limitations of traditional MTAs.
The Decline
Sendmail’s market share erosion was gradual but relentless. By the mid-2000s, Postfix had overtaken it in new installations. Exim captured the web hosting market through its adoption by cPanel. Cloud email services — Gmail, Office 365, Exchange Online — removed the need for many organizations to run their own mail servers at all.
The factors that drove sendmail’s decline mirrored the factors that had driven its success, only in reverse. It had dominated because it was the default on BSD systems and because alternatives were immature. As alternatives matured and offered dramatically better configuration interfaces and security architectures, the inertia that had kept administrators on sendmail wasn’t strong enough to resist the pull of something better.
The Legacy
Sendmail’s legacy is enormous, even if the software itself is no longer dominant. It proved that a single program could handle the complexity of global email routing. It trained a generation of systems administrators in the realities of internet infrastructure. Its security failures drove the development of more secure alternatives and helped establish the principle that internet-facing software must be designed with security as a primary concern, not an afterthought.
The sendmail.cf configuration file, for all its notorious difficulty, also influenced how we think about mail routing. The concept of address rewriting rules, mail routing tables, and configurable delivery agents became standard features of every MTA that followed.
Eric Allman’s creation ran the internet’s email for longer and more comprehensively than any software before or since. That it was eventually superseded doesn’t diminish the achievement. It just confirms what every infrastructure engineer eventually learns: the tools that build an era are rarely the tools that sustain the next one.
Infographic
Share this visual summary. Right-click to save.
Related Events
Frequently Asked Questions
What is sendmail?
Sendmail is a mail transfer agent (MTA) created by Eric Allman in 1983 at the University of California, Berkeley. It routes and delivers email between servers using SMTP. At its peak in the 1990s, sendmail handled more than 70% of all email on the internet.
Is sendmail still used today?
Sendmail is still maintained and receives occasional updates, but its market share has declined dramatically. Most organizations have migrated to Postfix, Exim, or cloud-based email services. It remains in production at some legacy installations but is rarely chosen for new deployments.
Why was sendmail so complex?
Sendmail's configuration file (sendmail.cf) used a cryptic macro language with single-character operators and rewriting rules that were notoriously difficult to read and write. The complexity stemmed from sendmail's need to handle multiple incompatible mail protocols and address formats from the early internet era.
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.