The Inevitable Demise of Small Mail Servers

16 years ago, my first job was migrating the ETH electrical engineering department’s mail server from Sendmail to Postfix. Since that time, mail infrastructure and mail security are among my favorite topics. I wrote open-source software for mail servers, and also spoke at conferences on how to fight spam.

Still, I am now moving my personal mail domain from a self-managed linux server to a cloud service. I decided to do it, because I realized that it was in the best interest of my (few) users. Let me explain…

Until about two or three years ago, mail security was focusing on the biggest challenges that users faced: spam. The effectiveness of a mail security solution was measured the amount of spam detected.

Nowadays, the amount of spam keeps dropping, and mail filtering is considered a commodity that everybody provides. One kind of malicious email has stayed dangerous though, and it has become the biggest threat to users: phishing attacks.

In response to that, the mail security community has changed tactics: instead of analyzing the mail text for known patterns of spam and viruses, which doesn’t work so well for phishing mails, it now focuses on something neglected for a long time: authentication and reputation.

The most important authentication mechanism for mails is DMARC, “Domain-based Message Authentication, Reporting & Conformance”. It’s a mechanism by which you can verify that a mail, for example from paypal.com, is really coming from Paypal. It prevents spoofing of the From: header by third parties.

When AOL went live with a DMARC policy for their domains in April 2014, it marked the start of a very wide deployment, and is now used for mail domains such as citibank.com or facebook.com.

Another trend in mail security is the focus on reputation. Instead of treating all mails the same, independently of where they are sent from, mails are more and more being analyzed for where they come from, instead of only what they contain. If, for example, my mail server uses an IP address that was previously used to send spam mails, its reputation is going to be bad, and further mails from the same IP will be also categorized as spam.

With DMARC, not only the reputation of the sending IP addresses can be used, but that of the authenticated mail domains as well. So Google is for example likely to trust mails coming from paypal.com, if it is DMARC-authenticated. DMARC ARC even makes it possible to evaluate the reputation of servers that only relay mails (for mailing-lists for example).

So this is the trend: evaluate the reputation of mail servers and mail domains, possibly also based on user feedback, and categorize the mails accordingly. It makes a lot of sense, and it really improves mail security for all of us. But there is one downside: small mail domains can’t build their reputation enough “up” to be able to reliably send emails. Even if their reputation is neutral, it just takes a single bad report, and deliverability is impacted.

My sister told me a few days ago that she couldn’t send mails to hotmail.com anymore. I checked, and indeed hotmail.com was reporting that my IP address had a bad reputation and therefore mails were rejected. The bad reputation was coming from the fact that somebody else in the same netblock sent spam mails. I had to route the mails for hotmail.com to another server, so that it appears as coming from a different IP. It showed me that big mail hosters are becoming more and more aggressive in using reputation-based systems, and it was becoming increasingly difficult for me to pass these tests.

If you think that filtering spam mails is difficult, think again. Today, the hardest job of a mail administrator is ensuring mail deliverability. If you operate a small mail domain on your own server, good luck. I am moving to the cloud.