Learn Mailserver - History, Background & Why You Need It

#Introduction

In episode 0 we made sure the environment was ready. Now let's step back and answer a question that's rarely asked but hugely influential: where does email come from, and why are Postfix, Dovecot, and Roundcube the choices we'll build together?

This isn't just trivia. Understanding email's history explains why the protocols look "archaic", why anti-spam is this strict, and why protecting your IP's reputation matters more than simply installing packages. Like understanding the history of a language, understanding email's history means you don't just know how to use it — you know when and why things are done a certain way.

We'll trace the birth of SMTP, the open relay and spam era that changed everything, the origins of our three main components, and close with the problems they solve and the challenges ahead.

#The Birth of Email and the SMTP Standard

Email was born long before the web. In 1971, Ray Tomlinson chose the @ symbol to separate the user name from the machine — and the email address format hasn't changed since. But the official protocol wasn't standardized until more than a decade later.

#From RFC 821 to ESMTP

In 1982, RFC 821 released the Simple Mail Transfer Protocol (SMTP) as the official standard. Its architecture was simple: a server accepts messages from another server, stores them, then forwards them toward the destination. No authentication, no encryption — the internet back then was a small circle of researchers who trusted each other.

The next major step came in 2008 when RFC 5321 and 5322 overhauled the standard into Extended SMTP (ESMTP). SMTP gained extensions such as STARTTLS, message size, and richer message formats. The protocol we configure in this series is a direct descendant of this standard — the mail.example.com you'll see appearing in logs is the trace of ESMTP at work every time an email leaves your server.

#The Open Relay and Spam Era

The original SMTP design had a fatal flaw in the open internet era: many servers were configured as open relays — willing to forward email from anyone to anyone. In the 1990s, as email came into mainstream use, spammers exploited this to flood the world with unsolicited email.

Out of that crisis came the anti-spam standards we still use: SPF (2003), DKIM (2007), and DMARC (2012). Email that anyone could send with no proof of identity now requires signatures and authorization records in DNS.

#The Birth of Postfix, Dovecot, and Roundcube

As SMTP grew up, the three projects at the heart of this series were born to answer their own specific problems.

#Wietse Venema and Postfix

Before Postfix, the king of MTAs was sendmail — extremely powerful, but its configuration was notoriously complex and it was vulnerable. Wietse Venema (creator of tcpwrappers) wrote Postfix and released it in 1998 as a safer, modular, and far easier-to-configure alternative. Its design separates small processes that communicate with each other, so a single failing process doesn't bring everything down. More than two decades later, Postfix remains the default MTA on almost every Linux distribution.

#Dovecot Faces Down the Aging IMAP Servers

On the delivery side, aging IMAP servers like UW-IMAP and Courier were showing their age: insecure, slow, and hard to scale. Dovecot was born in 2002 and quickly became the de facto standard — thanks to full support for IMAP, POP3, LMTP, SASL authentication, and a complete plugin ecosystem. Just as Postfix won the hearts of sysadmins in the MTA world, Dovecot did the same in the mailbox world.

#Roundcube for Webmail

When Gmail exploded in popularity in the mid-2000s, the world began to expect reading email from a browser. Roundcube was first released in 2008 as an open source webmail with a desktop-client-style interface. It sits on top of an existing IMAP server, making it the perfect complement to Postfix + Dovecot.

#Development in the 2020s

The Postfix + Dovecot + Roundcube combination remains relevant in the 2020s, but the ecosystem is evolving:

• TLS 1.3 speeds up and secures certificate negotiation on all email ports.
• DMARC enforcement is increasingly mandated: big mailbox providers are starting to reject email without strong authentication.
• BIMI (Brand Indicators for Message Identification) lets company logos appear in the inbox.
• DANE and MTA-STS force end-to-end TLS between email servers, not just "best effort".

All of these trends directly affect the configuration you'll learn — especially episodes 5, 6, 17, and 18. You can still see the traces of that era directly in DNS:

dig TXT example.com +short
dig TXT _dmarc.example.com +short

The first output contains the SPF record, the second the DMARC policy. If both queries return empty, email from your domain will struggle to prove its identity in the enforcement era — a topic covered thoroughly in episodes 5 and 17.

#Email Development Timeline

To make it easier to see the historical leaps, here's a quick timeline:

The last row is the era you're living in now: there's no more "best effort" — connections between servers are increasingly forced to be encrypted and identity is checked more and more often.

#The Problems It Solves

Why bother self-hosting? This question deserves an answer before you spend the next 22 episodes. The main arguments:

• Independence from Gmail/Outlook. All your email, contact data, and user metadata lives on your server, not in someone else's storage warehouse.
• Privacy and data ownership. You decide who can read what, how long it's kept, and who has access.
• Domain and policy customization. Your own domain can have quota, retention, filter, and branding policies entirely under your control.
• Cost at a certain scale. For dozens to hundreds of accounts, self-hosting on a VPS is often cheaper than per-user managed service licenses.

#The Challenges Ahead

Honestly: a self-hosted mail server is not a one-time job. The main challenges:

• Deliverability. Legitimate email can end up in spam if IP reputation, SPF, DKIM, or DMARC isn't perfect.
• Security maintenance. Three components plus a database and filters must be updated regularly to close CVEs.
• Ongoing anti-spam. Spam is always evolving; your filter configuration needs periodic adjustment.

The good news: this entire series is designed to tackle those challenges one by one — from the foundations in episode 2 to the production checklist in episode 22.

#Conclusion

Episode 1 has mapped out email's history: from RFC 821 (1982) to ESMTP (2008), the open relay era that spawned spam and the SPF/DKIM/DMARC standards, and then the birth of Postfix (1998), Dovecot (2002), and Roundcube (2008) as answers to the problems of their times.

Key takeaways:

• SMTP was born without authentication; security is a layer added later.
• Postfix, Dovecot, and Roundcube were born to replace their aging predecessors.
• The 2020s strengthen DMARC enforcement, TLS, DANE, and MTA-STS.
• Self-hosting gives you independence and data ownership, but demands a maintenance commitment.
• Deliverability is a permanent challenge that will accompany us through episode 22.

Now you know why everything exists. In the next episode, episode 2, we'll map out the core concepts and main architecture: who MUA, MTA, and MDA are, how email flows from sender to recipient, and which ports we'll open. See you in episode 2!