A. Preface This is the second incarnation of my Postfix+Dovecot tutorial with a SQLite database backend. It's actually about the sixth incarnation of my own implementation, which as this project begins, is still running the second version. (I never did, never will, write about that version.) While writing the first tutorial, I learned a lot of useful things, so this time, I plan to put those to use. Like most mail server tutorials you might find on the web, this one began from the author's quest to learn something new. Unlike many of them, however, the new thing for me was neither Postfix nor Dovecot. I was already very strong in Postfix and capable in Dovecot, but I lacked practical experience in SQL and database design. The first tutorial showed that. I hope this one is much better in that regard (although surely there is still room for improvement.) What I set out to do here was to show a single SQLite database as the sole data source for the mail server. That is not entirely possible, however. The Postfix example includes postscreen, which needs cidr: or texthash: maps stored in memory. There is also a pcre:helo_checks file. If it is possible to emulate a regexp/pcre lookup in SQLite, I do not yet know how to do it. (I know there is a REGEXP operator in SQLite which invokes an undefined user function regexp(), but there might be issues beyond that. Postfix knows to handle regexp/pcre lookups differently, as documented in each manual for table-driven mechanisms in section 5.) Also, both Postfix and Dovecot are using the system user database. While there is a small, apparently unmaintained libnss-sqlite project, I made no attempt to use it here. That could be done easily enough, simply adding tables to that database and pointing Postfix and Dovecot at it, but I did not try it. I did manage to show a system which uses no hash: maps at all. Postfix is not able at this time (if ever) to support "default_database_type = sqlite", if for no other reason than the driver now is read-only. So your BDB or DBM (or possibly CDB) is still required. B. Who should (or might) find this of interest? I think experienced Postfix administrators will be interested in the way many major features have been implemented here. I impressed myself with it, if that means anything. :) These features are enumerated below, to-wit: 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. This one implements all four classes, and thus answers one of the FAQs we see on the Postfix-users mailing list: "Can I have local and virtual users on the same machine?" 2. Complete and solid implementation of transport maps. Postfix has great power and flexibility in the choices give to a postmaster for mail delivery. Transport(5) maps allow us to override delivery defaults per address. This example implements per-address transport capability. Almost all the howtos I found are using a MySQL backend. This means Postfix 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.