Virtual Hosting with Postfix, Part 1 and 2

Virtual Hosting with Postfix, part one
http://www.howtoforge.com/linux_postfix_virtual_hosting
Submitted by joe on Tue, 2005-04-12 10:48. :: Postfix
Version 1.0

Author: Joe Topjian <joe [at] adminspotting [dot] net>
Last edited 04/11/2005
The virtual domain support in Postfix is actually quite robust. There are three different ways you host virtual domains with Postfix and they're all described here. We'll be looking at the third one: separate domains and non-unix accounts.

Why this one? Because in the end, this options gives us the most flexibility. It's a little more complicated to set up and understand but well worth it when you're hosting several domains.

Our end goal is to have an email server that supports mail delivery to multiple domains. Each email address will be authentic to only that domain. For example, joe@domain1.com and joe@domain2.com are two different accounts that each receive different mail.

To start out, we're going to turn all domains into virtual hosts. Even if you have Postfix set up with a single domain, we're going to make that domain virtual. You don't need to do this, but I do because I think it's more organized. Having Postfix host one real domain and the rest virtual means that you will always need to configure Postfix twice: once for each type of domain. To do that, we'll change our myhostname line in main.cf to read:

myhostname = localhost

Next we're going to add the following virtual domain information to main.cf (all of which will be explained after):

virtual_mailbox_domains = /etc/postfix/vhosts.txt

virtual_mailbox_base = /var/spool/vmail
virtual_mailbox_maps = hash:/etc/postfix/vmaps.txt
virtual_uid_maps = static:1000
virtual_gid_maps = static:1000
virtual_alias_maps = hash:/etc/postfix/valias.txt
In the first line, we're using a text file called vhosts.txt. You can actually name this anything you want. Inside this text file will be a simple one-column list of all the domains you are hosting. For example:

domain1.com
domain2.com
virtual.org


The next line specifies the base directory where we shall store all of our mail. Again, you can choose anything you want.

The third line points to a textfile I called vmaps.txt. This is a two column text file. The first column specifies a virtual email address. The second column specifies that persons mailbox location. Just like with real domain hosting, if you specify a / at the end of the location, it becomes Maildir format. If not, it is mbox. I have hash specified because I'm also turning vmaps.txt into a hash file by running:

postmap vmaps.txt

This results in a file called vmaps.txt.db. Postfix is able to lookup information in hashes faster than a normal text file.

The contents of vmaps.txt looks like this:

joe@domain1.com domain1.com/joe/
joe@domain2.com domain2.com/joe/
john@virtual.org virtual.org/john/


Take a look at the second column. The value is appended to our virtual_mailbox_base line. So the absolute path of the virtual mailbox becomes, for example, /var/spool/vmail/domain1.com/joe/. Don't forget to actually make the directories domain1.com and joe. Since this mailbox is in maildir format, we'll need 3 subdirectories under this mailbox: new, cur, tmp. There are several scripts around to do this, but basically this works just fine:

mkdir new cur tmp
chmod 700 new cur tmp


The next two lines define an account we'll set up that will have permission to access the mailboxes. Yes, one account will have the ability to read all the virtual email. Yes, this can be considered a security problem. Please do your best to ensure no one can become this user. We'll call the account "virtual". Add it any way you want to the system (eg, useradd) and make note of it's uid and gid.

The final line specifies a text file where we can place aliases for virtual accounts. The contents looks like this:

joe@domain1.com joe@yahoo.com


Finally, you'll need to give ownership to the mailboxes to the virtual user. Running this will take care of it:

chown -R virtual:virtual /var/spool/vmail

And that's it. Just run a "postfix reload" and you are all set. Of course now we need a way to actually retrieve the email. I'll do that in Part Two.

Virtual Hosting with Postfix, part two
Submitted by joe on Fri, 2005-04-15 11: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.
Part One: http://www.howtoforge.com/linux_postfix_virtual_hosting
Original location of this document: http://adminspotting.net/howtos/postfixvirtual2.html
Originally Posted by Skylinux @ 2005-12-31 12:41:42

No Comments yet .....