A home for your virtual users’ mail
We're not having our mailboxes owned one-to-one by real local user accounts, but we do need some kind of user account to give us a context under which to store mail. And we don't really want to use an existing user account, either—we want another layer of privilege segregation to help keep things secure. So we need to create an actual for-real account that will own the directories where we're going to keep all of our virtual users' e-mail folders.
There's already a directory on the server,
where local mail would be delivered for local accounts (before we
started futzing around with all this virtual user mapping stuff). So
when we create our virtual mail-owning user account, we'll make a
subdirectory under that directory as that user's home directory—and therefore, as the top of our mail store.
Most guides have you creating this user and assigning it a UID and GID of 5000—that's "user ID" and "group ID," the unique identifiers assigned to Unix security principals—and we'll stick with that so that if you ever end up looking at someone else's guide to do some stuff, there's less chance of getting mixed up.
We'll create a group with GID 5000, then create a user with UID 5000 and also force its home directory to be where we want. Do this with the following commands in your root shell:
Cot those doves!
Postfix is now mostly configured (though we'll need to come back to
it), so now it's time to turn our attention to our MDA, Dovecot. Just as
with Postfix, our
mail-stack-delivery install has
helpfully preconfigured Dovecot with some good defaults. And just as
with Postfix, we're going to keep some and change some.
The very first thing we'll want to do, though, is get
Dovecot upgraded to a newer version. We're still a couple of months away
from a finalized download of Ubuntu 14.04, so the
package for 12.04 has an older Dovecot in it. Not to worry, though—this
is easily fixed. We'll just add a repository with a newer version and
upgrade. In your same trusty root shell, first make sure you have the
correct utility installed to easily add repositories:
After that's installed, we'll add the correct repository for the latest Dovecot, then update our package list and install it:
Our Dovecot's main configuration options are contained in a nicely curated set of files in
/etc/dovecot/conf.d—if you look in that directory, you'll see a whole bunch of them. The one created specially by the
mail-stack-delivery package is named, appropriately,
01-mail-stack-delivery.conf, and it contains most (but not all) of the directives we need to fiddle with to make Dovecot do what we want.
In the test virtual machine I set up to walk through the
configuration for this write-up, I ran into an issue starting up Dovecot
for the first time. The application complained that the config file
containing the default SSL/TLS certificate and key locations for Dovecot
pointed at locations that couldn't be accessed. That's all right—we're
going to change that stuff anyway, so a great place to start is to
comment out the offending lines. Open up
/etc/dovecot/conf.d/10-ssl.conf for editing and put a "#" character in front of lines 12 and 13—the ones with the
Once that's done, open up
/etc/dovecot/conf.d/01-mail-stack-delivery.conf and do some surgery. When you're done, the file should look like this:
(Make sure to remove the line breaks I added on the
We'll walk through this config in just a moment, but first we need to comment out a few things in the other config files that will otherwise override our choices here.
10-mail.confand comment out the
mail_locationline (add a "#" in front of it)
10-auth.confand comment out
auth_mechanisms = plain
auth-system.conf.extand comment out every uncommented line in the
passdbstanza, including its start and end lines
- Also in
auth-system.conf.ext, comment out every uncommented line in the
userdbstanza, including its start and end lines
The other files in the configuration directory contain all kinds of
excellent information and alternate configuration choices for Dovecot,
but we're taking a pretty substantial configuration shortcut by sticking
As with Postfix, I'm not going to go through every single option, but here's the gist of what we've got going on in
First, we're restricting Dovecot to using IMAP and disabling POP3
altogether. If you want to use POP3, you're welcome to, but you're on
your own for that. The other supported protocol,
sieve, is what we'll use to set up powerful and flexible server-side mail filtering—more on that in part 3.
Next, we're enabling SSL and feeding Dovecot the location of your
domain's private key and certificate, just like we did with Postfix (and
note the less-than signs at the beginning of those lines—those are not
typos, and they must be present). We're also telling Dovecot where your
system's list of trusted root certificates is stored so that it knows
how to validate SSL/TLS certificates presented by clients trying to
check their mail. Unlike Postfix, Dovecot isn't running in a chroot
jail, and you can give it the path to
/etc/ssl/certs rather than needing to use a single root CA file.
directives. These are vital, and they tell Dovecot where and how to
deliver your e-mail. The home directive tells Dovecot where it will be
storing user-specific files, and we're specifying the home directory of
the vmail user we created earlier:
/var/mail/vmail. We've got two variables appended onto the end of that location:
%d, which stands for the domain of the virtual user whose mail we're delivering, and
%n, which stands for the virtual user's name. Taken together, this means Dovecot will store files for "email@example.com" at
The location directive we're using tells Dovecot that we're going to be using "maildir" format for our e-mail. This means our inbox and its folders will exist on the server as actual directories, and the e-mails will be stored as individual files. Maildir is one of two common e-mail storage mechanisms; the other is MBOX, which keeps all messages in a single long file. Both formats have their advantages and disadvantages; we're going with maildir because it's easier to do stuff to individual messages from the command line this way (which can be important when we get into setting up and training our anti-spam system in part 3).
The location directive uses the same format as the home directive,
specifying the same location with the same two variables, and appends a
The last directive in the first chunk specifies the characters that Dovecot will allow for virtual user usernames. If you want to include non-US characters in your e-mail addresses, you'll need to edit this line.
Protocols and authentication
Next, we have two protocol sections; these define some additional parameters around how we want Dovecot to act with IMAP and as an LDA (local delivery agent). In the LDA section, you can see that we're enabling the Sieve plug-in—Sieve will let us build rules for filtering mail, and we'll get into that in part 3.
After that, there's a plugin section where we add some more Sieve options (again, we'll get into this in part 3) and then a line where we define our allowed authentication mechanism ("plain login"). We're allowing Dovecot to receive plain passwords from clients—in other words, we're allowing users to send their passwords to the server "in the clear." This sounds like a bad idea, but we're also requiring SSL/TLS encryption; connections from users will already be encrypted with SSL/TLS, so adding another layer of encryption is a little like wearing a belt with your suspenders. If you'd like to change this, you're welcome to, but forcing client-side password encryption can cause problems with some mail programs.
passdb section is of particular import. Here we
define where and how we're storing passwords for our users—we're going
to use a flat file containing our passwords, enciphered with salted
SHA512 (which we'll create and populate in just a moment). The options
set in this section ensure that if a user enters an incorrect password,
they won't be able to access e-mail. This is obviously a big deal.
Next we set our
userdb options, which can be a complex
section if you want to set up lots of users (both real and virtual) and
store lots of metadata about them. We, however, do not—so the section is
short. The only user Dovecot needs to be concerned about is our "vmail"
virtual mail handling account, and here we tell it that it will be
using that account's context—and only that account's context—to deliver
There are two more things in the file—first, we increase the logging
level of Dovecot's "auth" facility so that we can spot failed login
/var/log/mail.log. Lastly, the
section defines the method by which Dovecot will talk to Postfix. This
is where we create the unix socket that Postfix sends mail to—it's also
where we set the permissions on that socket.
Passwords for your users
Before we leave Dovecot, though, we need to set up SMTP and IMAP passwords for our virtual users so that you can connect to your server with your mail client and send and receive mail. As mentioned above, there's a wide range of password storage options, including a SQL database—in fact, storing passwords in a SQL database gives you the advantage of being able to offer users self-service password changes. However, because this is intended to be a single-user (or at most a very limited trusted few users) system, we're going to store our passwords encrypted in a flat file.
That file is
/etc/dovecot/passwd.db, as noted in the big
config file above, and we need to manually create it and fill it with
passwords. We'll be using the SHA512 crypto algorithm with a salt to
encipher our passwords; we'll also do the enciphering interactively so
that our plaintext passwords aren't saved in the bash terminal history.
First, generate your passwords with the
This will prompt you for a password and ask you to confirm it, then it will spit out an encrypted string. Since we have three virtual users (you, postbot, and webmaster), we'll need three passwords, so you'll want to run this three times—once for each user, using the passwords you want those accounts to authenticate with.
Then create a new file named
/etc/dovecot/passwd.db and make its contents look like this:
That's three lines, each starting with the account's e-mail address, then a colon, and then the whole enciphered password string for that account.
Default folders—the inbox and everything after
The very, very last thing to edit is the file
which is where we'll define what folders get created for each virtual
user. This is how we ensure that everyone has a sent folder, a drafts
folder, a trash folder, and a spam/junk folder.
The file already has all of this predefined, but we need to tweak it a bit to ensure that these folders get auto-created the first time one of your virtual users logs in and so your local mail program identifies them correctly as well.
15-mailboxes.conf for editing and add
auto = subscribe inside the curly braces for each folder. When you're done, the file should look like this (ignoring the commented lines):
Now, restart Dovecot with
service dovecot restart, and check its configuration with
dovecot -n. You should see something that looks like this:
(Note that if you receive an error stating that
is an unknown or invalid setting then you've almost certainly skipped a
step. Add the Dovecot PPA and upgrade Dovecot to the latest version as
described earlier in the guide, and then try again.)
This was a long, long guide—but we're at the end of part 2!
At this point, we've got a mostly ready Postfix install and a mostly ready Dovecot install. There are still a few mysterious commented sections in our config files, but fear not—we'll address all of those in the next part.
What remains to be done? The next part of our guide will involve a lot of work with DNS, both internal and external. We need to tell both computers on our local LAN and also computers on the Internet how to find our mail server, and we need to also add some special DNS entries that will help us prove that the e-mails we send are legit and not spam.
We'll also be setting up our anti-spam solution, Spamassassin, along with a virus scanner. We'll talk about opening up some ports and exposing our mail server to the Internet for the first time—though not before checking to make sure that everything's working and locked down tight.
Finally, in part 4, we'll dig into webmail with Roundcube. Webmail is an optional component. Your e-mail server will work perfectly well after part 3—but a lot of people use webmail and it's definitely nice to have—provided it's properly secured.
See you all next week.