** WHAT IS HERE? This is a mostly-complete implementation of a Postfix MTA and Dovecot IMAP mail server using a SQLite database for user and other data. An introduction to this implementation is here: 0-intro Next, a detailed discussion of the schema, and how/where to set up the database, is here: 1-sqlite The sample data is in a SQL file which can be fed into sqlite3(1): mail.sql ("sqlite3 -init mail.sql /etc/postfix/private/mail.sqlite" creates and populates the database.) Or, for those who might actually want to implement this in the real world, just the schema: schema.sql Postfix configuration is under postfix/ : postfix/ main.cf (and other files referenced in main.cf) query/ contains the query files referenced in main.cf Most of that mess plus more long-winded commentary is here: 2-postfix Dovecot configuration is under dovecot/ : dovecot/ README conf.d/ dovecot.conf sql-deny.conf.ext sql.conf.ext Modular configuration files under dovecot/conf.d/ : conf.d/ 10-auth.conf 10-logging.conf 10-mail.conf 10-master.conf 10-ssl.conf 15-lda.conf 20-imap.conf 20-lmtp.conf 20-pop3.conf 90-acl.conf 90-plugin.conf auth-deny.conf.ext auth-master.conf.ext auth-sql.conf.ext auth-system.conf.ext All the Dovecot mess and some more added commentary is here: 3-dovecot A file notes the changes since the first public posting of this on 2012-02-19 (the rewrite of what first appeared in 2012 January.) There's also a file which mentions what is yet to come: CHANGES TODO And finally, a tarball of all the files, e.g.: postfix-dovecot-sqlite-20120219.tar.gz latest.tar.gz With a symbolic link, "latest.tar.gz", pointing to the most recent version. Old copies (such as the previous version) might be found somewhere under here: old/ You shouldn't care about those unless you were here earlier and want to see what changed. Oh, and because Google cached the original filename before I actually went semi-public with the first version, I keep that name as a hardlink to Yours Truly, the README file: postfix-dovecot-sqlite.howto ** WHY IS IT HERE? Most third-party mail server howto documentation appears to be written as an exercise for the author. This is no exception. I am learning SQL and sqlite3. But, I do think it might be interesting to postmasters. This isn't one of those "copy/paste everything it says here to become Instant Gmail." Certain features you might want/need are not covered. It has, however, implemented many major features of Postfix in a way that I think is interesting: All address classes All domain lists in a single table True per-address: transport(5) maps virtual(8) UID/GID maps smtpd(8) recipient access maps (restriction classes) The transport maps implementation has the stability of local files (BDB or CDB lookups) with the power of SQL. Likewise, the access lookup, which leverages Postfix restriction classes, is similar in capability to a policy service without the reliance on an external process. The Dovecot side isn't quite as revolutionary. The SQL deny passdb covering both system and SQL users is interesting, as is the way the database is shared. Otherwise it's just standard stuff. ** WHO SHOULD CARE? The target audience is very small. But if you want to learn more about Postfix, this might teach you something. Let's just say this is aimed primarily at those who want to learn, or are already fluent in, Postfix, and secondarily at other mail system administrators. Don't take it as authoritative on SQLite: as per above, I am learning. With luck, maybe someone who is better at it will point out ways in which I can improve. ** BUGS AND ERRATA The main thing to mention here is that as of 2012-02-19 the Postfix part has only been tested "in theory". All the queries work as expected using postmap(1) with "-q". I have not tried it in a live setting, nor even in a complete test install. I'll probably get to that in the next week or so, after which this note will be removed, and changes noted in CHANGES. One feature I know to be broken is the restriction class lookup for catchall addresses. The only way I know to fix it is to add a domain- only lookup after the per-address one. This would only ever be reached for catchall addresses. It is shown as a commented example in main.cf and as an extra query file. You shouldn't use catchalls anyway, and I got tired of thinking about it, so I took the easy way out. Another broken feature is that virtual_alias_maps cannot do a lookup of an unqualified localpart address. Since both virtual_alias_maps and alias_maps are implemented in the same database table, and since that functionality is fully covered by alias_maps, I'm calling this a "wontfix" bug. There's another "wontfix" bug somewhere out there. I think it's rather silly, perhaps even too silly to call it a bug. So I'm compromising: I tell you here that it exists, but you have to read the document to find out what it is! ** COMMENTS AND SUGGESTIONS are solicited and welcome, please write to: . Thank you for your interest.