Mail server using Postfix, Dovecot

I know there are an inordinate amount of posts out there showing you how to configure a full-stack mail server. They always target a specific Linux distro, and blast through the whole process, without actually telling you why you're doing any of it, or how it all works. How do you know what to modify to fit your own configuration that way? How do you maintain a stack like that when you don't know how all the pieces fit together? Why should these tutorials expect you to patch and compile core components from source?!

So I'd like to take some time to fix those problems, and discuss my own full-stack configuration, and how it all works.

1. Stack Overview
2. Stack Interaction
3. Preparation
3.1. User Account
3.2. SSL Certificates
4. Installation
5. PostfixAdmin
6. Appendix A: Example Configuration Files
7. Appendix B: References

1. Stack Overview

I personally use Ubuntu Linux, but any other Unix-based solution should work fairly the same. My mail server uses Postfix for SMTP, Dovecot for IMAP and SASL, and SpamAssassin for filtering out the junk. Management of virtual domains, mailboxes, and aliases is handled using PostfixAdmin's excellent web interface. Each mailbox has both IMAP and web access, and the "antispam" plugin for Dovecot automates the process of retraining the spam filters whenever a user moves messages in or out of their Spam folder.

Benefits of this setup:

Ease of maintenance, using PostfixAdmin and shell
A split data store that's still easy to back up
A large selection of mail clients for the user while allowing them to check their mail from home or any other computer

Downsides of the setup, or ignored topics:

A shared spam filter database, although the usefulness of separate spam data is outweighed by the size of the database in my opinion
No self-service method for editing sieve/whitelist

2. Stack Interaction

The end goal of this process is to have a chain of interactions between all the pieces in the mail stack. I'll describe the entire stack here so that you can understand where everything is heading.

PostfixAdmin will populate the MySQL database with the virtual domains, mailboxes, and aliases that define your mail accounts. Each virtual domain corresponds to an actual domain that your server will accept mail. Mailboxes represent the end-user accounts that your server will recognize, separate from the login accounts on your server. Aliases are secondary names that point at virtual mailboxes; for instance, if you want your mailbox user@your.domain to also receive mail addressed to client@your.domain without a separate login.

Dovecot will connect to the database to get the list of virtual mailboxes and aliases. Dovecot will act as not only the IMAP server for mail clients like Thunderbird, but also as the SASL host, which allows Postfix to know what mailboxes and aliases are valid endpoints, and it will also act as the Local Delivery Agent once mail has been accepted by Postfix.

Postfix acts as the SMTP server, and will either accept incoming mail for valid mailboxes and aliases, or relay outgoing mail from valid users to other domains on the internet. In this configuration, Postfix will deny both incoming mail to mailboxes that don't exist, and deny outgoing mail relayed from clients that have not provided valid authentication against the SASL from Dovecot. This prevents our Postfix install from being an "open relay", which will quickly get your domain and IP address blacklisted as a spam source.

SpamAssassin sits in between Postfix and Dovecot, looking at each message accepted by Postfix to determine if it is spam or ham, marking the message appropriately, and then passing it to Dovecot for delivery. In cases where the user has reclassified a message as spam or ham (by moving it in or out of their Spam folder, respectively), SpamAssassin will update its database if needed. This configuration will not quarantine spam messages in a special location, instead preferring to let Dovecot's Sieve filter the message into the user's Spam folder, so that they can deal with Spam in the same manner from any native or web-based mail client.

As a quick review:

Incoming mail accepted by Postfix is passed to SpamAssassin, which marks the message appropriately and then passes the message to Dovecot, which delivers the message to the user's mailbox, using Sieve to filter ham to the user's Inbox and spam to the user's Spam folder.
Outgoing mail will be relayed by Postfix only if a user authenticates with the same information used to authenticate with Dovecot, allowing users to send and receive mail regardless of their location, without creating an open relay.

3. Preparation

3.1. User Account

The first thing I do is create an account and matching group on my machine that will own all of the mail-related information. I named them it "vmail", and assigned an arbitrary ID of 900 — lower than the IDs used for regular users, but high enough that it won't collide with automatically created accounts. The directory where all the mail data will be placed is created automatically with the vmail user; I chose /srv/mail to fit into my existing schema, but /home/vmail could work just as well.

# addgroup --system --gid 900 vmail
# adduser --system --disabled-login --gid 900 --uid 900 --home /srv/mail vmail

3.2. SSL Certificates

You will also need/want to generate a set of SSL certificates for your server, for use by both the webserver for secure admin access, and by Postfix and Dovecot so that user passwords aren't being sent in the clear. The need for valid certs cannot be more important, and there are many alternatives to Verisign, including StartSSL, which provide inexpensive certificates that will validate in any browser. StartSSL will even provide free certificates, so there is no reason to risk security by using self-signed certificates.

Once you have the certificate and key files, make sure you place them on the server in a location that can only be accessed by the root account. No other user will need access to the certificates; Apache, Dovecot and Postfix will all load the certificate information before dropping root privileges.

4. Installation

With one exception for the antispam plugin, everything I used came from Ubuntu's package repository or doesn't require compilation. Package names (or availability) may differ, in which case following the links above to the individual projects should help out; you can always resort to compiling from scratch.

The next step is to install the core mail stack packages that you will need. If you feel like you know what you're doing, you should be able to get away with replacing MySQL with PostgreSQL, but I have not tried that with my configurations. Otherwise, the software to install includes:

Apache server with PHP
MySQL server
Postfix, including TLS and MySQL support
Dovecot, including IMAPd and headers
SASL libraries
SpamAssassin, including the spamc client

On Ubuntu or Debian, you can install all these packages with the following command:

# aptitude install apache2 libapache2-mod-php5 php5-mysql mysql-server \
  postfix postfix-mysql postfix-tls dovecot-dev dovecot-imapd libsasl2-2 \
  libsasl2-modules libsasl2-modules-sql sasl2-bin spamassassin spamc

During the setup, you'll need to provide a root password for the MySQL server, and select that you want to set up Postfix as an "Internet Site". Once that's done, it's time to start setting up the databases, install PostfixAdmin, and configure the stack.

5. PostfixAdmin

You will need to start the next phase by downloading and extracting the latest version of PostfixAdmin.

6. Appendix A: Example Configuration Files

Below if a list of example configuration files, used for my server stack at LeetCode.net. If you prefer, you can download a comprehensive archive instead.

NoSwap.com