Preface: Why sqlite? And, who should read this?

I like what sqlite.org says about SQLite:
	Small. Fast. Reliable.
	Choose any three.

With sqlite, Postfix has both the speed and absolute reliability of
local files, and the strength and flexibility of SQL.

No, this wouldn't be suited for every Postfix server; you'd probably
want PostgreSQL and/or LDAP for busy clusters. But with appropriate
management tools (which are not yet written as of 2012-January) this one
could probably scale up very well.

SQLite does have limits, but for my needs, it's excellent. It lacks
access control, but I have used filesystem permissions to keep the data
reasonably safe. I can add on tables as needed, such as for additional
access(5) lookups. It's easy and automatable to keep offsite backups of
essential mail server data.

My target audience here are experienced mail administrators. If you have
experience in Postfix, you'll probably be impressed with what this
example can do. (I am!) And if you're not experienced in Postfix, you
can be well on your way with this.

The high points of this example as compared to other third-party howto
documents as you can find:

1. Complete implementation of address classes.

Most howto documents are for virtual mailbox hosting only, and many I
looked at seemed to be poorly understood by their authors.

2. Complete and solid implementation of transport maps.

Postfix has great power and flexibility in how a postmaster can choose
to deliver mail. Transport(5) maps allow us to override delivery
defaults per address. This example implements per-address transport
capability.

Almost all the howtos you can find are using a MySQL backend. This means
that the Postfix service depends on mysqld, and things turn ugly when
transport_maps are not available. SQLite saves us from this. Postfix
processes will read directly from the database, which, likely being
cached in system memory, will be very fast.

3. Per-address virtual UID/GID maps

Many howtos (including the Postfix VIRTUAL_README) use static UID/GID
mapping for virtual delivery. This example is capable of the greater
security of per-address UID/GID. (For ease of administration, the
default is to use a static GID and per-domain UID, but non-default
examples are demonstrated.)

4. Per-address smtpd recipient restrictions

Using the powerful feature of smtpd restriction classes combined with
per-address SQL queries, here we have something which is comparable in
function to Postfix policy services, but without relying on an external
process.


A. Overview

This is a multiple address class Postfix MTA with Dovecot IMAP/SASL/POP3
(POP3, yuck, but some of my users are firmly stuck in the 1990's.) This
was implemented on a Slackware Linux (x86_64) with a source install of
Postfix, a Slackbuilds.org install of Dovecot, and the distro package of
SQLite. It aims to be distribution-neutral in scope. Those who have a
strong basis in POSIX concepts and the use of their own chosen
Unix[-like] operating system will have no trouble translating this to
their own platform. You can apt-get, emerge or yum or even "make ; make
install" to your heart's content, but that stuff is not covered here.

Minimum versions required: Postfix 2.8, Dovecot 2.x, SQLite 3.x. The
latter, a minimum version is unknown, but at this writing the SQLite
project recommends 3.7.9.

Postfix address classes include local (delivery to Unix accounts and
aliases), relay (accepting mail as MX but passing on elsewhere to be the
final destination), virtual alias (accepting mail as MX, but redirecting
mail to real addresses in other domains), and virtual mailbox (delivery
to local mailboxes not associated with a system user account.) For more
on address classes, see the Postfix Address Class README. We implement
all four in this example.

I consider myself very strong in Postfix administration, competent to
strong in Dovecot, and a beginner in SQLite. I am sure that the latter
shows to the DBAs among the audience. Feedback and suggestions for
improvement are welcome.

Caution: this is not a replacement for documentation of the software
projects mentioned. Neither is it a substitute for understanding all the
basics you need to know in order to run a mail server.

What is this? This is a recipe, to be used by an experienced "chef".
That said, this might be a good way to learn, but not if people (and
their money) are depending on you. Start out small, build on it.

What is this not? It's not a whole server with everything you might
want. There's no shiny GUI for user/database management. (What I use for
database management: sqlite3(1) in a shell.) It's not going to include
content filtering, nor DKIM signing, nor TLS, and it only touches
somewhat on SASL. No third-party delivery agents are used, just
Postfix's native local(8) and virtual(8). (Since we did set up Dovecot,
it would be trivial to activate Dovecot's LDA.)

I'm trying to teach you to fish here; I am not throwing you a fish.

Beware of the kitchen-sink-style howtos which tell you everything to
type to end up with a mail server that does everything. You might get
what you wanted, if you and the author were careful, but you won't know
how it works. (In many cases these howtos are written by people who seem
to lack in-depth understanding of the subjects they try to document.)

Woe be unto you if/when something like an automated distro upgrade
breaks it! Interestingly, most of the kitchen-sink-style howtos are
implemented on systems which have automated upgrade tools, and it is a
sadly common occurence to see victims of this in help forums.

Again, this can be built upon. Focus on learning the whys, and the hows
will follow along meekly. If you don't think you need the whys, why do
you want to run a mail server at all? Consider outsourcing your mail
service; you will save yourself a lot of headaches, and probably some
money too, if time is money.

I presume that you start out with the right software compiled with the
right options, and already installed on the system. Links which can help
with this are in the bibliography at the end. One quick shortcut which
might save you some time: Postfix and Dovecot do not need to be compiled
in any particular order; they do not link against one another. However,
sqlite and any other libraries you will want to use must be installed
first.