HELO, world

The first thing two mail servers say to each other is hello.

One opens a TCP connection on port 25, the other answers with a greeting, and then the client introduces itself with a single line:

HELO mail.example.com

That command is older than most of the people reading this. It was specified in RFC 821 in 1982, back when the entire list of hosts on the internet fit in a text file you could download. HELO is misspelled for the most boring reason imaginable: early SMTP commands were four characters, so HELLO lost a letter and never got it back. We’ve all been saying hello wrong to each other for forty years and the mail still gets through.

We liked that. A company that runs email infrastructure, naming its blog after the handshake that starts every message, with the same typo every engineer recognizes from their first hello, world program. So: HELO, world.

Why bother

Mailprotector has been doing email security for a long time. In that time we’ve accumulated the kind of knowledge that doesn’t show up in product docs: the failure modes of greylisting under load, what a DNS resolver does to your tail latency when it gets unhappy, why a perfectly valid message can sit in a queue for six hours, how spammers actually probe your defenses versus how the blog posts say they do.

Most of that lived in our heads, a few internal runbooks, and the memory of whoever was on call the night it broke. That’s a bad place for it. When a new engineer joins, they relearn it the slow way. When we solve something genuinely interesting, it stays inside the building.

This blog is where we move that knowledge into the open. Some of it will be useful to other people building mail systems. Some of it will only matter to us, written down so we stop solving the same problem twice.

What goes here

A few kinds of posts, roughly:

Stories from the edge, where our servers meet the rest of the internet. Most of the interesting bugs in email live in the gap between what the RFCs say and what real senders actually do.

Deep dives on the parts of email that are easy to get wrong. SPF, DKIM, DMARC, TLS, the difference between a 4xx and a 5xx and why getting that wrong costs you real mail.

Notes on how we work. How we test a system whose whole job is to talk to untrusted strangers, how we ship without paging ourselves, what our on-call actually looks like.

The occasional honest postmortem. The ones where we caused the problem ourselves are usually the most instructive, so we’ll write those too.

We’re going to try to write the way we’d explain something to a colleague at the next desk. Specific, a little opinionated, with the actual commands and the actual numbers where we can share them.

A small promise

We’ll keep it real. No invented metrics to make a point land, no pretending a fix was clean when it took three tries. If a post says we lost a weekend to something dumb, we lost a weekend to something dumb.

The mail server is waiting for the next line. Let’s get into it.