Today's Deep-Dive: Postfix

All programmers are optimists.

It's quite the opening line.

Sounds a bit like a fortune cookie,

but I'm guessing there's more to it.

There is.

It's from Frederick P. Brooks, Jr.,

from the Mythical Man Month.

And it's the very first thing you

see on the home page for the software

we're talking about today.

And I just love that energy.

Because when you think about the sheer chaos of the internet,

the spam, the bots, the crashes, you

have to be an optimist to build something

that handles our communication.

Oh, absolutely.

You'd have to believe it's possible to bring

some order to all that chaos.

A pessimist would just unplug the server and, I don't know,

go live in a cave.

Exactly.

So today we're doing something a little different.

We're going under the hood of something

we all use constantly, every single day,

without a second thought.

We're talking about Postfix.

The engine that actually runs our email.

Right.

Most people just click Send and assume

some kind of magic happens.

But there's this piece of software catching

that message, figuring out where it goes,

fighting off the bad guys, and making sure it

doesn't just disappear.

And we're going to demystify it.

That is the mission.

We're going to explain this so that even a total beginner can

get it.

We want to make this technical server software understandable,

even if you're not a sysadmin.

Sounds good.

But before we dive into how your email actually

travels the world, we have to give a quick shout out

to the folks who make this deep dive possible.

That's right.

Safe server.

Kimmert sich das Hosting dieser Software und unterstützt dich bei deiner digitalen

Transformation.

Mehr Infos unter www.safeserver.dady.

Excellent.

So let's go back to that quote.

All programmers are optimists.

Who is the optimist behind Postfix?

So this story starts with a guy named Vizi Venema.

And we're going back a bit here to the late 90s

when he was at IBM Research.

Right.

And to really get why what Vizi built was so revolutionary,

you have to understand what he was looking at back then.

In the 90s, if you ran a mail server,

you were almost definitely using a program called SendMail.

And I'm guessing SendMail wasn't exactly perfect.

That is a very polite way to put it.

SendMail was the standard, sure, but it was just notoriously

difficult to configure.

Its config file looked like someone had just smashed

their face on the keyboard.

Oh, wow.

But even worse than that, it was a security nightmare.

How so?

Well, it was a monolithic program.

That means it was one giant piece of code

that did everything.

And because it did everything, it ran with root privileges.

OK, root.

For beginners listening, that's basically

god mode on a computer, right?

You can do anything.

Exactly.

The keys to the entire kingdom.

So if a hacker found just one bug in SendMail.

He didn't just break the mail server.

They own the entire machine.

That's terrifying.

So Waitsy Venema wanted to build a better alternative.

He wanted to build the anti-SendMail.

And he really stuck with it.

I mean, even after he went to Google,

he was there for eight years, he kept maintaining Postfix.

This wasn't just some corporate project for him.

It was a passion project.

That's rare.

So let's talk about the design.

You said SendMail was a monolith.

How is Postfix different?

Waitsy built it on three pillars.

Fast, easy to administer, and secure.

And the secure part is where the genius comes in.

Instead of one giant program, Postfix

is a collection of many small specialized programs.

Like a team of specialists instead of one overwork manager

trying to do it all.

Precisely.

You have one little program that just listens

for network connections.

A different one puts mail in the queue.

Another one writes it to the desk.

And the key is, most of these little programs

do not run with root privileges.

So if a hacker breaks into the program listening

for connections?

They're stuck.

They're in a little box.

They can't get to the rest of the system.

It's a defense in depth strategy.

That makes so much sense.

But here's the part I found really clever.

What I'm calling the Trojan horse strategy.

Wheatsey knew that sysadmins are creatures of habit.

They'd spent years learning those cryptic send mail commands.

Right.

You can't just throw all that knowledge out.

So if he made Postfix totally alien, nobody would switch.

Exactly.

So he made the outside, the commands you type,

have a very send mail-ish flavor.

If you knew send mail, you could basically

start using Postfix right away.

But the inside, the engine, was completely different.

Totally different.

It's like he swapped out the engine of a classic car

for a modern electric one, but kept the dashboard exactly

the same so the driver wouldn't freak out.

That's a great analogy.

And because of that philosophy, it just spread everywhere.

I saw the list of systems it runs on.

It's a roll call of heavy duty computing.

AIX, BSD, HVUX, Linux, Mac OS, you name it.

If it's a UNIX-like system, Postfix

is probably at home there.

So for anyone listening, think of it

like the universal translator of mail servers.

It just works pretty much anywhere.

It does, but that brings up a really important question.

Postfix has been around a while.

And in tech, software usually ages like milk, not wine.

So how does it stay relevant in the age of the cloud

and modern apps?

That is the big question.

We're in the era of Docker and Kubernetes.

You'd think a legacy mail server would be completely obsolete.

But it's not.

And that's because Postfix has evolved.

If you look at the 3.x versions, like 3.3 and 3.4,

you see this huge push toward containerization.

OK, let's unpack containerization,

because that's a buzzword you hear all the time.

Think of it like this.

Old software, you installed it directly on the computer.

It was messy.

Today, we package software up in a sealed shipping container

with all its dependencies.

Like a pre-packed lunchbox for an application.

Exactly.

And you can ship that container anywhere.

But software inside that box needs to act differently.

For example, it often needs to be the boss process, what

we call PID1.

Postfix added support for that.

And the logging thing.

I found this fascinating.

Old software wrote its logs, its diary to a text

file on the hard drive.

But in the cloud, that's a disaster.

It is.

Because containers can just vanish.

If it crashes, the log file inside it is gone forever.

You've lost all the evidence.

So where should the logs go?

Modern systems want the app to just shout its logs

out the front door to sit out.

The cloud platform catches them and stores them

safely somewhere else.

And Postfix learned to shout.

In version 3.4, yes.

It learned to shout.

And that sounds like a tiny detail, but it's a huge deal.

It means Postfix is acting like a modern cloud native app.

It's learning the new language.

Speaking of which, let's talk data.

Because automation is everything now.

Yes, and robots do not like reading messy text files.

They like structured data, specifically JSON.

Which is just a format that makes

it easy for computers to read.

And I saw Postfix 3.11 and added JSON output

for its command tools.

It did.

So now a script, a robot can query Postfix,

get a clean JSON response, and manage thousands

of servers automatically.

It makes Postfix easy for other machines to manage.

And it's not just text files for user data anymore either.

It can talk to all sorts of databases.

Oh, the list is extensive.

It's not just text files anymore.

Postfix 3.9 added support for MongoDB.

And it already supported MySQL, PostgreSQL, Swy, Redis.

Wait, MongoDB?

That's a super modern NoSQL database.

Why would an email server need to talk to that?

Think about a big company.

You have one central database with all your employees, right?

OK, sure.

Your single source of truth.

Exactly.

You don't have to remember to also go update a text

file on the mail server every time you hire or fire someone.

I get it.

So Postfix just plugs right into the main company database.

Right.

It asks the database in real time, does this user exist?

Are they still an employee?

If not, it rejects the mail.

It connects the email world directly

to the modern data world.

But connecting is only half the battle.

The other half is protection, because email

is the number one way the bad guys get in.

It's a very tough job.

And Postfix has some clever ways to handle it.

One of my favorites is a feature called Postscreen.

Postscreen.

Sounds like sunblock.

Think of it more like a zombie blocker.

A zombie blocker.

OK, I'm listening.

So you have all these compromised computers

out there, zombies that are part of botnets,

just spamming millions of servers.

If your mail server tries to have

a full, polite conversation with every single one,

it gets overwhelmed.

It runs out of resources.

Completely.

So Postscreen sits in front of the real server.

It does these really lightweight checks.

Is this IP on a blacklist?

Is it behaving strangely?

If it's a zombie, Postscreen blocks it

before it can waste the real server's time.

That's so smart.

Efficiency of security.

But what about the sneakier attacks?

I read about these trickle attacks.

Yes.

Imagine someone calls you, you say, hello.

And they say, hello, and then they wait 10 seconds.

Then they say, how, and wait another 10 seconds.

I'd hang up.

That's infuriating.

Exactly.

But old servers were too polite.

They'd wait.

And attackers would exploit that by sending data

incredibly slowly, one byte every few seconds,

just to tie up all the connection slots.

It's the passive aggressive denial of service attack.

It is.

But Postfix fought back.

They added per request deadlines and minimum data rates.

If you talk too slow, Postfix just hangs up on you.

Talk fast or get off the line.

I love it.

It's necessary.

And then, of course, there's encryption.

All the acronyms, TLS, SSL.

Right.

And Postfix is really modern here.

Back in version 2.11, they added support

for something called Dane TLS.

It's a way to use the DNS system itself to verify security

without necessarily needing a traditional certificate

authority.

It helps decentralize trust.

And then you have SNI, which lets one server host

multiple encrypted domains.

And require Teals.

That one sounds demanding.

It is.

It's a way for a sender to say, this message must be encrypted.

If you can't do it, don't even try to send it.

It's for when good enough security isn't good enough.

Which is critical.

But speaking of critical, there's

one area where Postfix is just absolutely obsessive.

And this is my favorite nerd corner fact about it.

I think I know where you're going.

The file system requirements.

Yes.

This blew my mind.

I always just assume when I save a file, it's saved.

But Postfix has some serious trust issues with hard drives.

It does, and for good reason.

It operates on a zero data loss mentality.

It requires that the file system properly

supports the fysync command.

OK, beginner translation time.

What is fysync?

So when a program tells a computer to write data,

the computer often cheats.

It sticks the data in fast memory and RAM and says,

OK, done.

It plans to actually write it to the physical disk later.

So the computer is lying to you?

It's being optimistic.

It assumes the power won't go out in the next two seconds.

But if it does, poof, the data is gone.

And for a mail server, that's a lost email.

Which Postfix finds completely unacceptable.

Fink is the command that says, no, you

will physically write this to the disk right now,

and you will not tell me you're done until you are actually

done.

I'll do it in a minute for an answer.

Never.

The documentation is explicit.

It says a file must not be lost.

If the system crashes right after Fink returns,

it demands that guarantee.

And it even warns about virtual machines, right?

Yes.

That's the amazing part.

It warns that the host machine can't cheat either.

The data has to go all the way to the physical metal.

That's digital banking level reliability.

It really is.

It shows that email isn't just casual chat.

It's infrastructure.

And Postfix takes its promises very, very seriously.

Which is funny, because we think of email as so instant,

but the back end is built to be bulletproof.

It has to be.

And it has to be global.

That's another area where it's adapted

with internationalization.

Right, because not everyone's email address

uses English characters.

Exactly.

For a long time, email was very ASCII-centric.

But Postfix 3.0 brought in full support for SMTPUTF8.

The ketty name.

It just means it can handle international email

addresses natively.

So email addresses and headers with, say,

Chinese characters or accents don't

turn into a bunch of gibberish.

That's huge for making the internet truly global.

And of course, it supported IPv6 for ages.

And it handles all the weird conversions

needed to make sure modern attachments don't

break old, ancient servers.

The universal translator, again, connecting

the old world to the new.

Exactly.

So when you step back, Postfix really is that, quote,

come to life.

All programmers are optimists.

But it's like, we'd see Venema was

an optimist who prepared for the absolute worst-case scenario.

That's a perfect description.

It's this optimistic workhorse.

It looks like the old stuff, but it

acts like modern infrastructure.

It speaks JSON.

It lives in containers.

It talks to MongoDB.

But deep down, it's all about that reliability.

That Fesync requirement is the heart of it.

It's like it's saying, I don't care how fast you want to go,

we are not losing this letter.

Precisely.

So what does this all mean for us,

the actual users hitting send?

Well, I think it leaves us with a provocative thought.

We live in this era of move fast and break things.

Apps crash, data glitches, services go down,

and we kind of just shrug.

But Postfix is a reminder that some software,

the deep plumbing of the internet,

is designed to never break things.

When you hit send on that important contract

or that job application, you're not relying on magic.

You're relying on that obsession.

You're relying on the fact that somewhere a server

is refusing to say okay until your message

is physically permanently written to a disk.

I love that, the invisible reliability

that keeps everything running.

Well, before we sign off, a quick reminder

about who helps keep us on the air.

SafeServer takes care of hosting this software

and supports you in your digital transformation.

More information at babyww.safe-server.iege.

Check them out.

And thank you for diving deep

into the internet's plumbing with us today.

Next time you send an email,

maybe take a second to appreciate the engine

getting it there.

See you on the next Deep Dive.

See you on the next Deep Dive.