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 as old as I am. 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 more than 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 more than 25 years. In that time we’ve accumulated the kind of knowledge that doesn’t show up in product docs. We know why we don’t greylist, after watching it delay real mail and annoy users. We know mail moves only as fast as your slowest DNS lookup, that a perfectly valid message can sit in a queue for hours, and how attackers really probe a filter, which is rarely how it gets written up. We once lost a Thanksgiving to a single inefficient regex rule that slowed every system to a crawl.

Most of that lived in our heads, 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 email 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, and how we design security products people actually enjoy using.

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. This is ours.