Virtual Hosting with Postfix, part two

Want to support HowtoForge? Become a subscriber!
 
Submitted by joe (Contact Author) (Forums) on Fri, 2005-04-15 10:01. :: Postfix
Version 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:

01 base_dir = /var/run/dovecot/
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 "joe@domain1.com". 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 "joe@domain1.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:

maildir:/var/spool/vmail/domain1.com/joe


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:

userdb
joe@domain1.com::1000:1000::/var/spool/vmail/domain1.com/:/bin/false::


passdb
joe@domain1.com:$1$G/FqlOG5$Vj0xmc9fKY.UVr8OWr/7C1


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:

$ telnet domain1.com 110
Trying 192.168.1.2
Connected to domain1.com
Escape character is '^]'.
+OK dovecot ready.
user joe@domain1.com
+OK
pass test
+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.


Please do not use the comment function to ask for help! If you need help, please use our forum.
Comments will be published after administrator approval.
Submitted by Anonymous (not registered) on Mon, 2006-06-12 04:35.

Note that, unfortunately, this article is out of date with the release of Dovecot 1.0. I will post back with more info once I get the changes figured out.

Submitted by Anonymous (not registered) on Mon, 2006-04-03 06:34.

Good Day

Excellent tuturiol on how to setup the Dovecot,but a few steps have been excluded from the above tuturiol.When adding the passdb file,the type of password has been exluded,this must be defined in the passdb file, so correct structure is as follows

passdb

joe@domain1.com:{PLAIN}$1$G/FqlOG5$Vj0xmc9fKY.UVr8OW

or what ever is needed in the {},please have a look at page to get all the correct information at the www.dovecot.org website

http://wiki.dovecot.org/Authentication?highlight=%28MD5%29

Good luck.

Submitted by Tharange (not registered) on Mon, 2013-05-20 08:53.

Thanks

Good tutorial and a good comment. I made my setup working.

{MD5-CRYPT} for MD5