Virtual Hosting with Postfix, part twoVersion 1.0
Author: Joe Topjian <joe [at] adminspotting [dot] net>
Last edited 04/15/2005
This article will pick up where the last one left off: how to actually retrieve the email we're storing in our virtual accounts. In the first article, I explained how we're using the third type of Postfix virtual hosting which is to use separate domains and non-unix accounts. The separate domains portion was covered fairly well. Now it's time to work on the non-unix accounts.
There are several popular techniques to do this using services such as OpenLDAP or MySQL and mixing that with Courier IMAP. We won't be using any of those. Instead, we're going to be using something much more simple: plain text files. If you have a few hundred email addresses that you are hosting, I could see the need for a directory service or database to help keep some sanity and organization to your accounting. On the other hand, if you're running a small to medium sized email server, there's really no need to toss a couple memory-intensive services into the mix. Scream blasphemy all you want, this is what I've used for years and it's been lightening fast and has never failed me.
In order to do this, we'll be using Dovecot. If you've never heard of it, you will now. Dovecot is extremely lightweight, flexible, and from what the author says, secure. Unfortunately, the documentation is pretty weak, but if you read the webpage, manpages, and config files, you should be able to pull through. If you're running Debian Sarge or Sid, you can install Dovecot with:
apt-get install dovecot-common dovecot-imapd dovecot-pop3d
My dovecot.conf file is a whopping 28 lines long and looks like this:
02 protocols = imap pop3 imaps pop3s
03 ssl_disable = no
04 ssl_cert_file = /etc/ssl/server.crt
05 ssl_key_file = /etc/ssl/server.key
06 ssl_parameters_file = /var/run/dovecot/ssl-parameters.dat
07 ssl_parameters_regenerate = 24
08 log_path = /var/log/dovecot
09 info_log_path = /var/log/dovecot.info
10 login_dir = /var/run/dovecot/login
11 login_chroot = yes
12 login = imap
13 login_executable = /usr/lib/dovecot/imap-login
14 login_user = dovecot
15 login = pop3
16 login_executable = /usr/lib/dovecot/pop3-login
17 verbose_ssl = yes
18 valid_chroot_dirs = /var/spool/vmail
19 default_mail_env = maildir:/var/spool/vmail/%d/%n
20 imap_executable = /usr/lib/dovecot/imap
21 pop3_executable = /usr/lib/dovecot/pop3
22 auth = default
23 auth_mechanisms = plain digest-md5
24 auth_userdb = passwd-file /etc/dovecot/users
25 auth_passdb = passwd-file /etc/dovecot/passwd
26 auth_executable = /usr/lib/dovecot/dovecot-auth
27 auth_user = root
28 auth_verbose = yes
Most of this is pretty self-explanatory and the configuration file provides a lot of hints about this, too. Basically, we're going to be using Dovecot to run imap, pop3, imaps, and pop3s and add some support for virtual hosting. Let's go over the lines that help us with the virtual hosting.
Line 19 is particularly useful. Since we're running a virtual hosting set up, the easiest way to distinguish one user from another is to have them log in with their full email address. For example, when I'm setting up my mail client, I wouldn't just put "joe" in for the username, I would put "firstname.lastname@example.org". Dovecot does some guessing on its end with your username. If it just sees something like "joe", it set's a variable called %n to "joe". If it sees "email@example.com", it will split it up and set %d to "domain1.com" and %n to "joe". Going off of that, if we replace the variables in line 19, we get something like:
This is exactly what we set up in Part One. OK, so now we've got dovecot taking the user to the correct mail directory, now we still need to authenticate them. Line 23 tells us we want to support two types of authentication methods: plain and digest-md5. Plain is what every client under the sun supports, so we'll go with that. The digest portion doesn't harm anything sitting there and if your client supports it, then by all means, use it!
Finally, on lines 24 and 25 we see a userdb file and passdb file. Think of these as a second /etc/passwd and /etc/shadow file. The format of these files goes like this:
That encrypted password is an MD5 hash of the word 'test'. mkpasswd is a great utility for generating MD5 passwords. The 1000:1000 corresponds to the uid and gid of the "virtual" user we created in Part One. The home directory includes everything but the word before the @ in the email address.
And that's really all there is to it. Make sure your /var/spool/vmail directory is owned by the "virtual" user and fire Dovecot up. You can test authentication by something like this:
Connected to domain1.com
Escape character is '^]'.
+OK dovecot ready.
+OK Logged in.
If you get that final +OK, you are all set and ready to go.
Since adding SSL support (IMAPs and POP3s) is so easy in Dovecot, I would highly recommend doing it. If you already have a self-signed certificate for your HTTP server, you can use the exact same one for Dovecot. If you don't have a self-signed certificate, google search instructions on how to. It's too easy not to do it.
This just about covers virtual hosting and Postfix. I'll admit that using Dovecot and plain textfiles is a bit different than what you might have read about before, but give it a chance and the simplicity should grow on you. You might also look at this and wonder why in the world you'd want to type so much just to create one user account (making the directory, adding the user to the vmaps file, adding the user to the passdb and userdb file, etc etc etc). Remember, scripting is the ultimate solution to repetitive tasks. Perl, Python, and just plain shell work wonders for this set up.
Original location of this document: http://adminspotting.net/howtos/postfixvirtual2.html