Biz & IT —

Taking e-mail back, part 2: Arming your server with Postfix and Dovecot

Our self-hosting e-mail series continues as we get our ducks—and doves—in a row.

Taking e-mail back, part 2: Arming your server with Postfix and Dovecot
Aurich Lawson

In our last episode...

Welcome back to our series on taking your e-mail back! In part 1, we looked at exactly why we're spending so much time discussing how to host your own e-mail server—something that is by all rights a solved problem in the modern Internet age. We touched briefly on concepts of ownership and security before talking about the responsibility that comes with that ownership and security. E-mail is like a puppy, and once you step up and own your own puppy, you've got to take care of it, clean up after it, and make sure evil people don't infect it with horrible viruses and transform it into a zombie.

(Whoa. That got a lot darker than I meant it to be.)

By the end of part 1, we had purchased a domain name, set up a basic server, and done a bare-bones installation of Postfix and Dovecot. Postfix, you'll recall, is our MTA (Mail Transfer Agent), the program responsible for actually sending and receiving e-mail between your domain and others. Dovecot, in turn, will be functioning as our MDA, or Mail Delivery Agent. (Detail-oriented readers will also correctly note that Dovecot is much more than just an MDA, but if we get too bogged down in semantics now, we'll be here all night). Dovecot is the thing that will sort incoming e-mail into your inbox, and it's also the thing you'll connect to with your own e-mail client to actually get your mail delivered to your desktop or laptop.

Here in part 2, we've got three primary tasks:

  • Acquire and install an SSL/TLS certificate for our mail server
  • Perform some basic Postfix configuration so that it can function as an MTA and work with Dovecot
  • Perform some basic Dovecot configuration, including setting up three virtual users and their mail directories

Let's get started.

One last thing...

Before we do anything else, it's time to update stuff. It's been more than a week since part 1 was published, and it's possible that critical updates have been issued since then.

To update your server, log in via ssh and run the following two commands:

$ sudo aptitude update
$ sudo aptitude upgrade

The first command will tell your server to refresh its list of packages from the remote package repositories, and the second will install any updates it finds. We'll be covering update strategies and server hardening in part 3 of the guide, but for now, it's enough to know that you should make an effort to do an update and install at least once every couple of days. As such, it's best to set up the server to automatically do this.

Also, before we do anything else, we should take a moment and do some basic securing of our server's remote access. At the very least, we need to set limits on which accounts are allowed to log on via ssh. This can be done by adding a line to the main configuration file for the ssh daemon. Using the text editor of your choice, edit the file /etc/ssh/sshd_config and add the following at the very bottom, substituting in the name of your account:

AllowUsers youraccount

Then restart the ssh daemon with the following command:

$ sudo restart ssh

The AllowUsers directive, as its name suggests, tells the ssh daemon which users are allowed to log on via ssh. Since we're going to be using virtual users for our mail accounts—more on that in a bit—we want to very strictly limit which accounts can actually log on to the box interactively. In fact, the only account that needs to be able to log on is yours, and so that's what we've just configured.

It's also a good idea to set up key-based ssh authentication. That's a little beyond the scope of this guide, but it's not difficult to do. The official Ubuntu documentation site has an excellent guide on getting key-based authentication working, and I highly recommend following it.

There are more security tweaks to do, like using iptables to limit authentication attempts, but we'll hold off on those until part 3. For now, it's time to get our SSL/TLS certificate!

Certifiable

When we set up a Web server in our previous series, getting SSL/TLS working was a recommended but optional step. However, it is most definitely not optional for this guide: you must have a valid SSL/TLS certificate for your mail server. "Valid" here means "issued by a recognized Certificate Authority (CA)," not something self-signed. Using self-signed certificates to identify your mail server to other mail servers is a great way to get other mail servers to refuse to deliver your messages. Then your mail server would be lonely because none of the other servers will want to talk to it, and that would be sad. You don't want your server to be sad, do you?

Fortunately, you can get a valid SSL/TLS certificate for free and without too much trouble. A few years ago, Ars published a guide on how to acquire a certificate from StartCom, and that's what we're going to use. If you already have a source for SSL/TLS certificates you'd prefer to go with, that's fine—as long as it's a valid CA that's universally recognized as a trusted root.

The guide linked in the previous paragraph ought to be enough to get you going, but we'll briefly run through the process. You'll need to head over to StartCom's StartSSL portal and sign up for an account. StartCom doesn't use usernames or passwords to authenticate you—instead, they use personal certificates, and by signing up, you'll be issued a personal certificate with which you can log in. If you're using Firefox, the certificate will automatically be installed in your browser's trust store; Chrome, Safari, and IE users instead use the operating system's certificate store.

Now that you can log in, you'll need to do a domain name validation. This will kick off a process wherein StartCom will send an e-mail containing a validation code to one of several e-mail addresses for your domain—webmaster@yourdomain.com, postmaster@yourdomain.com, hostmaster@yourdomain.com, or the e-mail address listed in your domain's whois record. Since we haven't configured e-mail for your domain yet (that's why you're reading this guide, after all) the first three won't work for us, but the last one will. The last address will be the one you supplied to your registrar in part 1, though it might show up as a proxy or "privacy guard" e-mail address. Regardless of whether it's your direct e-mail address or a proxy, you'll need to have access to that e-mail account to continue.

Starting the process of proving to the StartCom CA that we control a domain.
Enlarge / Starting the process of proving to the StartCom CA that we control a domain.

Once you've received your validation code, paste it into the appropriate field on the StartSSL page, thus confirming to StartCom that you're the person listed as being responsible for that domain. This gives you the right to request certificates for that domain. The basic free validation lets you request "class 1" certificates, which can be used for basic purposes; if you want to be able to do some more advanced tricks, you can pay $60 for an identity validation and gain the ability to generate "class 2" certificates. This is convenient, for example, if you want to create a "wildcard" certificate that's good for an unlimited number of names (see my personal site for an example of how a wildcard cert behaves—it's good for *.bigdinosaur.org, so I can use the same certificate on many different sites, as well as on my mail server).

Once we've proven that the domain is ours, we can request certificates for it.
Enlarge / Once we've proven that the domain is ours, we can request certificates for it.

After validating the domain, you can click on the Certificates Wizard tab and start the process of generating a certificate for your mail server. First you'll create a private key—set 4096 bits as the keysize and SHA2 as the algorithm. You'll also want to enter a password here, which will be used to encrypt your private key. The actual generation will take a minute or two, so be patient. Next, you'll be taken to a screen with a text box containing your private key. You'll eventually want to get this onto your mail server; for now, open a Notepad or TextEdit window and copy and paste in the entire key, including the parts at the beginning and end that look like comments. You can retrieve the key later through the StartSSL menu system, but it's a lot easier to keep it right at hand, since we'll need it in just a moment.

Now that you've got your key, you'll be able to select your validated domain from the next screen, and then after that you'll be able to provide a hostname for the server you want the certificate to apply to. This should match your mail server's name—so if your mail server's name is "mail.squidblaster.io," you'd make sure to put "mail" into the appropriate text field.

And then, boom, you've got an SSL/TLS certificate! It won't look like much—just a chunk of ciphertext—but that's what it's supposed to look like. Copy the whole thing (including the beginning and ending lines that look like comments) into a new Notepad or TextEdit window (again, you can retrieve it later from the StartSSL control panel, but we're about to make use of it).

We need one final file for maximum compatibility—StartCom's Class 1 Intermediate CA certificate, which is the certificate used by StartCom to sign your own server's certificate (and it, in turn, is signed by StartCom's root CA certificate). You can find it under the "Tool Box" tab, or you can get it right here.

Now, log on to your mail server via ssh. We're going to be doing a number of things that require root privilege, so for the sake of convenience we're going to launch a root shell using the sudo command:

$ sudo /bin/bash

After you type this command, the trailing character of your prompt will change from a "$" to a "#" to indicate that you are now logged into an account with root-level privilege.

We're going to put our certificate in /etc/ssl/private, so change to that directory (cd /etc/ssl/private) and fire up the text editor of your choice. First, create a file called ssl-key-encrypted-mail-yourdomain.key, paste your private key into it, and save it. If you're using vim as your editor, remember to type :set paste before pasting.

Next, in the same directory, create another file named ssl-cert-mail-yourdomain.pem and paste in the SSL-TLS certificate (again, make sure to use :set paste if you're using vim), then save and exit. Next, we'll combine your certificate and StartCom's Class 1 Intermediate CA certificate into what's called a "chain certificate"—two certificates in a single file. This is so clients who might trust StartCom's root but not trust any of its intermediate signing CAs can follow the validation up from your server's certificate without needing any outside help. First, get the intermediate CA file into the /etc/ssl/private directory, either through cutting and pasting or by simply downloading it directly with wget:

wget https://www.startssl.com/certs/sub.class1.server.ca.pem

Then, using the cat command and the handy-dandy abilities of the bash shell, concatenate the two files together like this:

cat ssl-cert-mail-yourdomain.pem sub.class1.server.ca.pem > ssl-chain-mail-yourdomain.pem

This will create a file named ssl-chain-mail-yourdomain.pem that we'll actually use as your mail server's certificate in both Postfix and Dovecot.

There are two more things we need to do. The first is to take our encrypted private key and decrypt it, because right now it's enciphered, and applications that want to use it (like Postfix and Dovecot) would have to prompt you for a password every time they were restarted in order to read it. To decrypt the key, use the following command:

openssl rsa -in ssl-key-encrypted-mail-yourdomain.key -out ssl-key-decrypted-mail-yourdomain.key

You'll be prompted for the password you originally entered into the StartSSL control panel during key generation, and then the OpenSSL utility will spit out a third file, named ssl-key-decrypted-mail-yourdomain.key.

Guard this file very carefully. It is a decrypted private key that can be used in combination with the SSL certificate to impersonate your site's identity. In fact, to help keep the key secure, we're going to change its permissions (along with those of the encrypted key) so that it's only readable by the root account. Run the following commands to make sure the key is appropriately accessible:

chown root:root ssl-key-*
chmod 400 ssl-key-*

This will ensure that the files' owner and group are both set to root and that the files' permissions are set to read-only by their owner and unreadable by all others.

Now that we've got our certificate ducks all in a row, it's time to turn our attention to configuring Postfix.

Channel Ars Technica