E-mail is old and complex. It's the oldest still-recognizable component of the Internet, with its modern incarnation having coalesced out of several different decades-old messaging technologies including ARPANET node-to-node messaging in the early 1970s. And though it remains a cornerstone of the Internet—the original killer app, really—it's also extraordinarily hard to do right.

We most often interact with e-mail servers through friendly Web-based front-ends or applications, but a tremendous amount of work goes into hiding the complexity that allows the whole system to work. E-mail functions in a poisoned and hostile environment, flooded by viruses and spam. The seemingly simple exchange of text-based messages operates under complex rules with complex tools, all necessary to keep the poison out and the system functioning and useful in spite of the abuse it's constantly under.

From a normal person's perspective, e-mail seems like a solved problem: sign up for Internet access and your ISP gives you an e-mail address. Google, Apple, Yahoo, or any number of other free e-mail providers will hook you up with e-mail accounts with gigabytes of space and plenty of cool value-added features. Why do battle with arcane dragons to roll your own e-mail solution?

I'll tell you why: because if it's in the cloud, it's not yours.

Because you must rely on others for your security. You have no control over who can read your correspondence—you must allow your data to be mined and your marketing profile extracted. You won't be told if your metadata is collected or if your inbox is vacuumed up by a secret government request. You consent to be not a customer but a product, and a product has no rights.

Well, to hell with that. It's your e-mail. And we're going to take it back.

This is hard and even a bit scary...

E-mail is hard. If you want an easier sysadmin project, go set up a Web server. E-mail is a lot more complex, with many more moving parts. On the other hand, your correspondence with others is one of the most personal aspects of your online life—in a medium ultimately made of text, your words are you. It's worth learning how to claw your online life back from those who would data mine and monetize it.

There are pitfalls and caveats—the biggest of which is that if you run your own e-mail server, you will be the sysadmin. The upside of this is that no bored or tired customer service rep about to go off-shift is going to fall for a social engineering attack and reset your e-mail password. The downside is that you are responsible for the care and feeding of your system. This is not an impossible task—it's not even really difficult—but it is non-trivial and never-ending. Applying critical updates is your responsibility. When do critical updates come out? That's your responsibility to keep track of, too.

Worst of all, if you screw up and your server is compromised or used as spam relay, your domain will almost certainly wind up on blacklists. Your ability to send and receive e-mail will be diminished or perhaps even eliminated altogether. And totally scrubbing yourself from the multitude of e-mail blacklists is about as difficult as trying to get off of the TSA's No Fly list.

You have been warned.

...but it’s also worth doing

OK, that ought to be enough to scare away the people who aren't serious. For those of you still with me: this is going to be a hell of a lot of fun, and you're going to learn a lot.

This is going to be multi-part series, and here in this first part we're going to ask (and answer) a bunch of questions about how we're going to set our e-mail server up. We'll also outline the applications we're going to use and talk about what they do. We expect this series will run over the course of the next few weeks; unlike our series on setting up a Web server, though, you won't be able to get started firing off e-mails after part 1—you need the whole thing in order for it all to work right.

This certainly isn't the only DIY e-mail tutorial on the Web. If you're eager to skip ahead and get started now, we suggest consulting Christoph Hass' excellent tutorial on Workaround.org—he makes many (but nowhere near all) of the same configuration choices that we will be making. However, Ars wouldn't be putting this guide together if we didn't have a few tricks up our sleeves—we've been in an e-mail configuration cave for the past month, and we have a lot of good information to share.

Prerequisites and assumptions—the where and the how

So you want your own e-mail server. Excellent! The first decision, before we even get into things like operating systems and applications, is where you're going to put it. If you're on a residential ISP connection, you will face a number of challenges in running an e-mail server out of your closet. In addition to almost certainly finding the standard set of e-mail TCP ports blocked, your IP address is also almost certainly already on one or more blacklists in order to cut down on the amount of spam being spewed out by virus-infected home computers. Whether or not you're actually spewing any spam is irrelevant—that ship has long since sailed, and residential IP addresses are almost universally considered poisoned. There are numerous tools you can use to see if your address is on a blacklist—make sure to check before you start.

If you just want to mostly follow along at home with a non-functional test domain for learning, then a virtual machine or spare closet server will do just fine; if you want to do it for real, you'll either need to be on a business-class connection with unblocked ports and a non-blacklisted IP address, or you'll need a hosting service. You don't need a monster dedicated server or anything, but you do need at least a VPS you can install software on from the command line. There are many options; I always recommend A Small Orange or Lithium Hosting, but if you're willing to sacrifice some performance, you can almost certainly host a small e-mail server on a free Amazon EC2 instance.

You're also going to need a domain (again, unless you're going to just play along and use a nonexistent test domain), and that means you're going to need a registrar and an external DNS provider. My personal recommendations for registrars are Namecheap and Gandi.net; both took hard anti-SOPA stances (see these links) and both offer two-factor authentication options. I have used both registrars, and they are both excellent.

One of the lessons reinforced by the recent @N Twitter account theft is that you should segregate your online services where it makes sense to do so. A significant component of the @N compromise came from the attacker gaining access to Naoki Hiroshima's GoDaddy account, with GoDaddy functioning not only as his registrar but also as the authoritative DNS source for Hiroshima's domains. Once in, the attacker was able to change at least one of those domains' MX records and thereby hijack delivery of that domain's e-mail.

We're going to attempt to mitigate that specific risk by using a separate DNS provider—specifically, we're going to use Amazon's Route 53 DNS service. That will limit the amount of immediate damage an attacker can do in the unlikely event of a compromise at your registrar.

"Ah," you say, "but if I use Amazon EC2 for my e-mail server and Amazon Route 53 for DNS, then I'm not segregating at all!" This is true, but Amazon gives you rich access control between different services; it's not difficult to ensure that one set of login credentials can only modify your EC2 server and a different set of credentials can only modify your Route 53 DNS settings.

There are also many other DNS providers if you want to physically distribute your eggs rather than rely on access control—and being paranoid about security is never unwise. For this guide, though, we'll be walking through the specific steps that I took when taking my own existing Google Apps-hosted domain and e-mail private—that means a physical server and Route 53 DNS (which ends up costing me about $2 a month).