Run your own email server, part 2
In this how-to we'll set up an email server from scratch using NetBSD.
A little background
Why would someone want to run her / his own email server? We have Google, Yahoo, Hotmail and other email services which are free, so why bother?
This isn't a rhetorical question. Talk to anyone who has run or runs an email server and you'll probably hear tales of how incredibly complex and arduous the process is. Mail server software is often horribly documented, with arcane features and specious configuration requirements which make all but the boldest of admins cringe. Let's not even discuss Microsoft Exchange's need for tens of thousands of dollars worth of hardware and licenses just to support a handful of users. But is it REALLY that hard, or is it simply that nobody has demystified the process?
Even if a straightforward guide existed (which we're working on here), why bother expending the energy to maintain an email server? As Fred Allen once said, "I can't understand why a person will take a year or two to write a novel when he can easily buy one for a few dollars", and the same can be said about running an email server. So why expend the energy?
For some of us, the answer is as simple as "because we can". Some of us like to learn by doing, and that alone is enough. For others, it's a lack of trust of companies to protect our data. With Yahoo allowing snooping on email, being lackadaisical about security, and AT&T, Verizon, Comcast, Time Warner, and others not really caring about security very much, one might want to take matters in to her / his own hands.
Even if security isn't a compelling reason, these larger companies lack flexibiliy. Can normal people communicate with actual humans at Google or Yahoo about emal issues? Can we find out why email which we know to be completely legitimate, sent by a 100% RFC compliant email server got dropped instead of delivered? If there's a way to talk to humans at these companies, I want to know! In the meanwhile, I'll run my own email server because of this, which I consider to be the most compelling reason (for me): deterministic email.
"Deterministic email? How is Gmail not deterministic? After all, if my email doesn't work, half the world's email doesn't work, so nobody is going to blame me. It's good enough."
I've heard arguments like this for ages. That's fine for them. But some of us like to know what's going on, or have compelling reasons to know what's going on. When someone says they didn't get a message, we'd like logs clearly showing exactly, unambiguously, what's going on. This reason alone is why I've set up in-house email servers for a number of small businesses in the last couple of years. The "cloud" has failed us by taking away determinism. More about this later, with examples.
On a VAX?
Why on a VAX? Well, aside from showing that setting up an email server isn't all that difficult, I also wanted to illustrate two other things. One, there's no compelling reason to ever need binaries. Literally the entire OS and all the software we need can be compiled from source. This appeals to those of us who'd prefer to not trust binaries, to those who like to keep the option open of modifying the code ourselves, or to those who want to run the software anywhere we want.
A more important, but less often considered, reason for preferring source compiled software is long term maintainability. What happens when a vulnerability for that mail server binary you downloaded two years ago comes out, and the person or people who originally created it are no longer around? Do you then have to switch completely to a different system? What a pain!
The second reason for setting up an email server on a VAX is to show that you don't need tremendous amounts of resources to run basic services. People refer to Raspberry Pis as too underpowered to host services, which is plainly ridiculous - we've been hosting email, web, DNS and all sorts of other things on machines with an order of magnitude (or more) less CPU, less memory and less storage for ages. Sure, things like SSL / TLS require CPU, but do they really need a 2+ GHz multi-core CPU with gigabytes of memory? Of course not. Here I'll show some real-world performance numbers on a real 1991 machine.
Finally, VAX hardware is damned cool. It's engineered and built different to a different standard than anything modern. It's no surprise that the machine used for these examples has been running for twenty five years and has outlasted several disks and some memory, but otherwise runs perfectly. It can boot from ethernet, has an always accessible system console, built-in diagnostics, ECC memory and more. Modern computers barely have these. This is modern retrocomputing - running up to date, portable software anywhere we want, even on an architecture which first came out in 1977 and hardware that's a quarter of a century old.
The first time I set up Sendmail was in 1996 or so. It was a complicated beast to set up with many confusing parts. After it was set up I felt the same apprehension as many other admins feel when dealing with complex software - I was afraid to change things lest I break something. But over the years I've set up Sendmail on new systems, tried a few different things, changed things to see what'd happen, and cleaned out things that weren't used any more. I even wrote a few Sendmail rulesets myself when I wanted something that didn't already exist. Even with the changes, it's surprising how similar the configuration is now to what I started with in 1996! So let's get started.
When I started this HOW-TO, there were a number of things I realized I'd need:
- A domain name
- A (relatively) static IP
- A place to host DNS
- An SSL certificate
- A cool, old machine on which to run this
I have a cable modem at home and the IP almost never changes. I'll use that, right? Unfortunately, no. Most residential providers don't let you connect to port 25 on other machines on the Internet, and some don't allow incoming connections to port 25. This would make an email server quite useless. Add the fact that many email servers use dynamic address blocklists, and that isn't really an option.
Luckily for me, my brother was smart and got a block of IPs back in 1990 which we can route as we please, even through a cable modem. For others, options are using an unused IP of your work's Internet feed (of course, ask first), renting an IP from any of a number of providers, or buying the cheapest of VPS (virtual private server) and port forwarding over a tunnel. We'll go over each of these.
This begs the question: if we're paying for a VPS, why not just run our mail server there? If that's good enough for you, then by all means, do so! For those of us who like the security of having our data physically in our possession, using a VPS to provide a static IP is a good way to run a mail server (and, perhaps, other services) wherever we want.
In the next part, we'll go over network configurations and get started with the process of getting an SSL certificate.