Inbox Zero
I used to run large-scale email delivery. Legacy territory, but I'm attached to it.
The first MTA I touched was sendmail. Few people could actually read a sendmail.cf file. Security bugs dropped weekly. It became a running joke.
When qmail appeared, the simplicity was striking. DJB's design philosophy was uncompromising. Up there with Larry Wall in my engineers I respect. Security first, strip everything else. But the license was peculiar, and most practical features lived as third-party patches. Knowing which patches to apply was a craft in itself. Postfix finally gave us an MTA with configuration a human could read.
Large-scale delivery was a war fought outside the mail spec. To be clear: not spam. We were a subsidiary of a public company, sending to opted-in members. The carriers still treated us like spammers.
Mobile carriers had peculiar behavior. Send to a nonexistent address, and normally you get a bounce. Some carriers returned nothing. Silent absorption, like UDP. No way to tell whether a message was delivered or swallowed. Carrier-level blocking was worse. Too many messages from one IP in a short window, and the whole IP got blocked. The unblock criteria were never published.
The countermeasure was brute force: line up more IPs. Distribute sends across multiple addresses, keep per-IP volume low, reduce block risk. Crude, but it was all we had.
Eventually the brute force evolved. We spun up freshly launched EC2 instances via the API, split the architecture into a controller and send nodes, and built a delivery system around it. Send nodes scaled with volume. Auto-scaling existed, but it was designed for web traffic, not email delivery. We had to build our own.
The landscape has since shifted entirely. Services like SendGrid handle delivery now. Nobody stands up their own MTA. DMARC, SPF, DKIM made domain authentication the standard. The axis of trust moved from IP address to domain reputation. The era of lining up IPs is over. Whether your email lands in the inbox is decided by your domain's sending history and reputation.
That EC2-based delivery system had an internal codename: suzume. Years later, I borrowed the name for an entirely different open-source project. The only thread connecting them is that both deal with the Japanese language. No trace of email delivery remains.
A colleague back then named the data-ingestion batch job suzume-feeder. Feeding the sparrows. I still envy that naming sense.