Qmail-Vmailmgr-Courier-SquirrelMail Installation Guide

Konstantin Riabitsev
icon@mricon.com

Version 0.99.1: April 9, 2k1

Abstract:

This document is useful for people who are looking to set up an e-mail system with an easy-to-use client webmail front end and support for name-based virtual domains. It proposes a Qmail-Vmailmgr-Courier-SquirrelMail tie-in as the best small to mid-class server solution. Latest version of this document can be found at http://www.mricon.com/SM/guide.


Contents

The problem

Say, you are looking to start your own small-to-medium hosting business and you need to come up with the best solution for an e-mail server. The things you are looking for are: I was facing the same problem and I have found that one of the best solutions would be to use Qmail-Courier-Vmailmgr-SquirrelMail tie-in. It is very easy to configure, runs very reliably, and has very good security features.

The Software

Operating System Software

Everything we are going to use can be configured on almost any UN*X system out there. I've had this setup running smoothly on Linux, FreeBSD, and OpenBSD. I am going to recommend using OpenBSD for this solution, but it doesn't really matter which UN*X system you are running. Whichever you are more comfortable with - that's the one you should use. I am going to write this document as if you had a BSD-like system (any BSD distribution, Linux Slackware, and others). If you have a Linux RedHat-like system with sysv-style init scripts, the difference would be in where you put your startup scripts. The only requirement is having common GNU tools installed, like GNU make, GNU tar, GNU grep, and etc.

This document assumes that you have successfully configured your system and are ready to put the e-mail stuff on it. I will not mention things like DNS/MX settings - other documents cover this topic better.

Linux users

If you are going to be using a package-based Linux system, e.g. Debian, RedHat, SuSE, or others, and prefer to install RPM or DEB files rather than build everything from the sources, you are encouraged to check out Dan Kuykendall's Qmail-Vmailmgr-Courier-imap HOWTO at Linux Documentation Project. The HOWTO covers installation and configuration of Qmail, Vmailmgr, and Courier-IMAP on Linux and provides links to where you may find pre-built binary packages.

You may find that document at the following address:
http://linuxdoc.org/HOWTO/Qmail-VMailMgr-Courier-imap-HOWTO.html

Stuff You Will Need

This shows latest versions at the time of writing. If newer versions are available, you should probably get them.

Setting up Qmail

Setting up Qmail is rather trivial, but here are most basic steps you need to take.

Preparing the scene

Before you do anything, you will need to remove any traces of Sendmail from your system. If you're running an RPM-based linux distribution, do it by executing:

root@mail:# rpm -e --nodeps sendmail
On BSD-based systems use pkg_delete or similar scripts.

Next, create a /var/qmail directory. You need to remember, that this is where qmail will store its queued e-mail, so if you want to be ready for some big traffic (remember the iloveyou!), you might want to make sure you have a reasonable amount of space available on this partition.

Qmail has very tight security features, and it achieves them by using six separate user accounts to process all the mail. You will need to create them before you can compile and install qmail. Do this by executing the following commands:

root@mail:# groupadd -g 1000 nofiles 
root@mail:# useradd -u 5000 -g nofiles -d /var/qmail/alias alias 
root@mail:# useradd -u 5001 -g nofiles -d /var/qmail qmaild 
root@mail:# useradd -u 5002 -g nofiles -d /var/qmail qmaill 
root@mail:# useradd -u 5003 -g nofiles -d /var/qmail qmailp 
root@mail:# groupadd -g 1001 qmail 
root@mail:# useradd -u 5004 -g qmail -d /var/qmail qmailq 
root@mail:# useradd -u 5005 -g qmail -d /var/qmail qmailr 
root@mail:# useradd -u 5006 -g qmail -d /var/qmail qmails
Of course, you can add them by editing the /etc/passwd file, or running vipw on BSD systems.

Compiling

Now that you have created the necessary users and made sure you have a sensible amount of free space in /var/qmail, you are ready to compile and install. This is very trivial and takes no time at all.

root@mail:# tar xzvf qmail-1.03.tar.gz 
root@mail:# cd qmail-1.03 
root@mail:# make && make setup check
If everything compiled without errors (which it should have), you are ready to configure qmail.

Configuring qmail

For the sake of providing examples I am going to assume that your hostname is ``mail.dexterslab.net''.

Go to /var/qmail/control directory:

root@mail:# cd /var/qmail/control 
root@mail:# echo mail.dexterslab.net > me 
root@mail:# echo mail.dexterslab.net > defaultdomain 
root@mail:# echo mail.dexterslab.net > rcpthosts 
root@mail:# echo mail.dexterslab.net > locals 
root@mail:# echo mail.dexterslab.net > plusdomain 
root@mail:# echo localhost >> locals 
root@mail:# echo localhost >> rcpthosts
This covers the basic installation. We will get to virtual domains setup at a later step, since it's much easier done with a simple script, than by hand.

Setting the sendmail wrapper

Since most systems cannot function without sendmail, qmail provides a sendmail wrapper. To activate it do this:

root@mail:# ln -s /var/qmail/bin/sendmail /usr/lib/sendmail 
root@mail:# ln -s /var/qmail/bin/sendmail /usr/sbin/sendmail
This should make every program totally oblivious to the fact that you're not really using sendmail any more.

Startup scripts

Go to /var/qmail/boot, find the file called ``home'' and move it to /var/qmail/rc.

root@mail:# cd /var/qmail/boot 
root@mail:# mv home ../rc
To run qmail all you have to do is execute:
root@mail:# /var/qmail/rc &
To have it started automatically you need to put ``/var/qmail/rc &'' into your /etc/rc.local file.1

After the machine is done booting, make sure your qmail is running by executing:

root@mail:# ps auxww | grep qmail
and find the ``qmail-lspawn'' process together with a few others. Test the system by sending a simple message like:
root@mail:# uname -a | mail dexter@remoteserver.com
Check your remote server and make sure you have received this e-mail. If something didn't work, check your /var/log/mail or /var/log/maillog or /var/log/messages (whichever) for a possible explanation. Sorry, troubleshooting is out of the scope of this document. Visit www.qmail.org for any support you need.

Setting up ucspi-tcp

Your mail server is no good if it can't accept SMTP connections. This is best done by using the ucspi-tcp package available from the same developers who wrote qmail.

Compiling ucspi-tcp

No sweat, as always. Simply do:

root@mail:# tar xzvf ucspi-tcp-0.88.tar.gz 
root@mail:# cd ucspi-tcp-0.88 
root@mail:# make && make setup check
This will compile and install ucspi-tcp files in your /usr/local directory.

Setting up tcprules

We want to make sure that nobody but our own clients are able to use our server to send outgoing mail. Otherwise we will have what is called an ``open relay'' - everyone will hate us and we'll end up on various spam blacklists. Not something we want.

To enable ``selective relaying'', we need to create a file called /etc/tcp.smtp. In this file we need to put something like this:

192.168.1.:allow,RELAYCLIENT=''
:allow
What this does is instructs qmail that it should allow outgoing e-mail only for people connecting from our subnet, which in this case is 192.168.1.0/24. You, of course, will need to change it to your own subnet if you want this to work. You may add as many subnets in, following the given example and putting each on a separate line, to make sure that all your clients are covered. Don't forget the last :allow on the line, or we won't accept any incoming mail for our clients either.

Once your /etc/tcp.smtp file is completed, you will need to compile it so it's ready to be used. Do this by executing:2

root@mail:# tcprules /etc/tcp.smtp.cdb \
/etc/tcp.smtp.tmp < /etc/tcp.smtp
The command will compile your rules and put them in a binary file /etc/tcp.smtp.cdb (you might want to make sure /usr/local/bin is in your $PATH). Remember that you will need to recompile the rules if you add any more subnets in. I found it useful to use this no-brain script whenever I needed to edit the rules:
-begin /usr/local/bin/tcprulesedit- 
#!/bin/sh 
vi /etc/tcp.smtp 
/usr/local/bin/tcprules /etc/tcp.smtp.cdb \ 
/etc/tcp.smtp.tmp < /etc/tcp.smtp 
-end /usr/local/bin/tcprulesedit-
Now editing rules is as simple as running tcprulesedit.

(You may wish to use other editor, not vi, if you are not comfortable with it).

Running tcpserver for SMTP

Running tcpserver is no easy task. ;) Well, it is, it just needs to be put in a nice script. The command line to execute tcpserver looks like this:

root@mail:# /usr/local/bin/tcpserver -x/etc/tcp.smtp.cdb \
-u5002 -g1000 0 smtp /var/qmail/bin/qmail-smtpd \
2>&1 | /var/qmail/bin/splogger &
A bit of explanation of what this does. -x/etc/tcp.smtp.cdb flag makes sure we use the relaying rules we have just compiled. -u5002 instructs tcpserver to run as user ``qmaild'' -g1000 is group ``nofiles'', 0 means that we want tcpserver to listen on all interfaces, smtp means we want it to bind to port 25 (the standard SMTP port used for mail exchange), /var/qmail/bin/qmail-smtpd instructs the tcpserver to run qmail-smtpd program after establishing connection, 2>&1 makes sure there isn't any garbage spewing onto the console and it all goes into the logs, and /var/qmail/bin/splogger makes certain we put stuff in /var/log/maillog. Quite simple, really.

Since we are going to be using tcpserver to also run pop3 later, I've found it convenient to create a separate script called ``runmail'' to put all these monstrous lines in. I advise you do the same and put the abovementioned long line in a script /usr/local/bin/runmail:

-begin /usr/local/bin/runmail-
#!/bin/sh 
/usr/local/bin/tcpserver -x/etc/tcp.smtp.cdb -u5002 -g1000 \
0 smtp /var/qmail/bin/qmail-smtpd 2>&1 \
| /var/qmail/bin/splogger &
-end /usr/local/bin/runmail-
Now all that's left to do is add ``/usr/local/bin/runmail'' line to our /etc/rc.local file to make sure that tcpserver is started during the boot-up. Be sure to set execute permissions on /usr/local/bin/runmail.

Checking to see if it worked

Check to see if you have done everything correctly by doing this:

root@mail:# telnet mail.dexterslab.net smtp
You should see:
Trying 192.168.1.1...
Connected to mail.dexterslab.net.
Escape character is ']'.
220 mail.dexterslab.net ESMTP
Try saying hello. Type in
HELO johnnybravo.com
It should say:
250 mail.dexterslab.net
Type ``quit'' to close connection. We will do serious testing later.

Useful Pointers for Qmail and Tcpserver

Qmail and tcpserver are a very flexible and extendable combination. You may tweak the system to your liking - visit http://www.qmail.org/ for a very lengthy list of software and enhancements available. Many end-users like some spam-protection, and although it is not possible to be 100% protected from spam, you may wish to enable MAPS RBL blackhole list of known spammers.

This is done by adding these flags to your tcpserver startup string:

/usr/local/bin/rblsmtpd -b -rrbl.maps.vix.com
Put it after ``0 smtp'' and before you invoke /var/qmail/bin/qmail-smtpd. This will first check the sender against a list of known spammers and blackhole the message if it's a known spam source. If you do this, then you should also modify your /etc/tcp.smtp rules and make them look like so:
192.168.1.:allow,RELAYCLIENT='',RBLSMTP=''
:allow
This will make sure that bandwidth and resources are not wasted checking your local clients against the list of known spammers (unless any of them happen to be on your subnet, of course).

Configuring VmailMgr

Get the latest version of vmailmgr from http://www.vmailmgr.org/. At the time of writing it is vmailmgr-0.96-9.tar.gz.

Building and installing VmailMgr

Untar the distribution and cd into the vmailmgr-0.96-9 directory. Now configure and build it:

root@mail:# ./configure
root@mail:# make && make install
That's it. If you encounter any problems, please refer to help docs and any info on the vmailmgr website, as troubleshooting is out of the scope of this document.

Configuring Virtual Domains

It is best of all to add and remove virtual domains by using a script, otherwise things get extensively verbose and tedious. Before we start, however, let's create a /home/dom directory where we will put all virtual domain directories, and add a ``dom'' group. This is done to organize everything nicely.

root@mail:# mkdir /home/dom
root@mail:# groupadd dom
Note that /home/dom is where all your incoming users' e-mail messages will reside, so depending on how many users you are going to support, you might want to make sure that you have plenty of space on this partition.

add_virt shell script

Now, here is a script I am using to add virtual domains:

-begin /usr/local/bin/add_virt- 
#!/bin/sh 
DGID="dom" 
DHOME="/home/dom" 
QHOME="/var/qmail" 
if test $UID != 0 ; then 
 echo "Error: Must be root"  
 exit 1  
fi 
if test ! $1; then  
 echo "Usage: add_virt newdomain.com"  
 exit 1  
fi 
if egrep "^$1:" /etc/passwd > /dev/null 2>&1; then 
 echo "Error: Cannot create domain. Domain exists" 
 exit 1  
fi 
NEWDOM=$1 
echo "Creating new domain '$NEWDOM'."  
useradd -d $DHOME/$NEWDOM -g $DGID -m $NEWDOM 
echo "Domain holder user created in $DHOME/$NEWDOM." 
echo "Please provide domain password for VmailMgr." 
passwd $NEWDOM 
echo -n "Adding domain to control/virtualdomains..." 
echo "$NEWDOM:$NEWDOM" >> $QHOME/control/virtualdomains 
echo "done" 
echo -n "Adding records to control/rcpthosts..." 
echo "$NEWDOM" >> $QHOME/control/rcpthosts 
echo "done" 
echo "Setting up the domain dir for vmailmgr..." 
su $NEWDOM -c "/usr/local/bin/vsetup" 
echo "...done" 
echo -n "Restarting Qmail..." 
killall qmail-lspawn 
$QHOME/rc & 
echo 
echo "All done! Domain $NEWDOM created." 
-end /usr/local/bin/add_virt-
It is pretty self-explanatory. First few lines setup some variables in case we want to shift things around later. Next, there are a few tests to make sure we have permissions to execute the scripts and add users, and a small test to see if we are trying to add a domain which already exists.

Next, we create a domain holder user with the same name as the domain itself. It certainly doesn't have to be this way, but it just makes sense and there isn't a reason not to name them the same. Setting a password is necessary since we will use it for authentication later with vmailmgr's web front-end. Needless to say, this should be a good password, not your dog's name (unless you named it '%AeZ+tk_' or something odd).

Last few lines add the new domain to qmail's virtualdomains and rcpthosts files, setup the new directory to be used with vmailmgr, and finally the script restarts qmail so these changes are reflected.3

Copy this script into a file in /usr/local/bin directory and set permissions to execute. You might want to check if your /usr/local/bin is in your $PATH if you don't want to type in the full path each time.

remove_virt shell script

Removing domains is also easy with a similar script. Here is what I am using:

-begin /usr/local/bin/remove_virt-
#!/bin/sh 
QHOME="/var/qmail" 
if test $UID != 0 ; then 
 echo "Error: Must be root" 
 exit 1  
fi 
if test ! $1; then 
 echo "Usage: remove_virt domain.com" 
 exit 1  
fi 
if egrep "^$1:" /etc/passwd > /dev/null 2>&1; then 
 echo "This will delete '$1' and all its users." 
 echo -n "Proceed? y/[n]: " 
 read YN  
 if test ! $YN; then YN="n"; fi 
 if test $YN != "y" ; then 
  echo "Aborted." 
  exit 1 
 fi  
else  
 echo "Error: Cannot remove domain. Domain not found" 
 exit 1  
fi  
OLDDOM=$1  
echo -n "Removing the domain with all user files..." 
userdel -r $OLDDOM 
echo "done" 
echo -n "Removing domain from qmail's control files..." 
cd $QHOME/control 
grep -v $OLDDOM virtualdomains > virt.new 
grep -v $OLDDOM rcpthosts > rcpt.new 
mv virt.new virtualdomains 
mv rcpt.new rcpthosts 
echo "done" 
echo -n "Restarting qmail..." 
killall qmail-lspawn 
$QHOME/rc & 
echo "done" 
echo 
echo "All done! Domain $OLDDOM deleted." 
-end /usr/local/bin/remove_virt-
All it does is first makes sure you know what you are doing, and then deletes the system user ``domain.com'' together with /home/dom/domain.com directory, thus deleting any and all users associated with it. Then it removes any mention of this domain name from qmail's control files and restarts qmail for you. My earlier note about strict BSD systems applies to this script, too.

Put this file with the other and set permissions to execute.

DNS settings

I will not cover these here, but all you need to do is provide an MX setting in the domain's zone file and point it to mail.dexterslab.net. Refer to your DNS server's manuals for more info.

Done

This is all you need to do with vmailmgr at this point. We will be using bits and pieces of vmailmgr later on, as well as will see how we can have a front-end to vmailmgr domains by configuring and running vmailmgrd.

Creating a sample user

Before we go on, let's create our own domain. We are most likely planning to receive all ``dexterslab.net'' mail on this server as well, therefore we will need to add it as we would any other virtual domain. Do so by using our script:

root@mail:# add_virt dexterslab.net
This creates the domain and makes it ready for adding users. Since we don't have vmailmgrd configured yet, we can't use a web front-end for this, therefore we will need to do it by hand. Do this by executing the following:
root@mail:# su dexterslab.net 
dexterslab.net@mail:$ vadduser dexter
Vmailmgr will prompt you for the password and once it's put in, the user is created. Don't forget to do ``su dexterslab.net'' before you run vadduser. When you have created the user, return back to root:
dexterslab.net@mail:$ exit 
root@mail:#
Now the system is ready to receive e-mail for dexter@dexterslab.net.

Setting qmail system aliases

Since we are going to provide a fully virtual access to all our users, we will most likely want all local mail (such as addressed to root or dexter) to be delivered to virtual users instead. This is done by setting a few aliases.

root@mail:# cd /var/qmail/alias 
root@mail:# echo '&dexter' > .qmail-root 
root@mail:# echo '&dexter' > .qmail-toor 
root@mail:# echo '&dexter' > .qmail-postmaster 
root@mail:# echo '&dexter' > .qmail-admin 
root@mail:# echo '&dexter@dexterslab.net' > .qmail-dexter
That should be enough. You may add as many as you need, making sure that all physical users' mail gets redirected to virtual servers (unless you know what you are doing).

Next, since an e-mail server is useless if users can't get to their e-mail, we will need to add two most popular protocols for accessing mailboxes - POP3 and IMAP4.

Configuring a POP3 server

We don't need to compile and install anything to enable POP3. However, we will need to modify our /usr/local/bin/runmail file and add another line to it, which will run another instance of tcpserver for the POP3 protocol.

Taking care of inetd

Many systems will have their own POP3 and IMAP handlers configured in inetd. This needs to be disabled, otherwise it will conflict with our installation. Edit your /etc/inetd.conf file, find a line starting with ``pop3'' and comment it out with a ``#'' sign. Do the same for the line beginning with ``imap'', if you have one. On systems using xinetd (e.g. RedHat 7.x), refer to your manuals on how to remove these services.

Restart inetd by running:

root@mail:# killall -HUP inetd

Tcpserver config line

mail@root:# /usr/local/bin/tcpserver -u0 -g0 0 110 \ 
/var/qmail/bin/qmail-popup mail.dexterslab.net \ 
/usr/local/bin/checkvpw /var/qmail/bin/qmail-pop3d \ 
Maildir 2>&1 | /var/qmail/bin/splogger &
This line is very similar to the one we wrote for SMTP. The flags this time are -u0, -g0 because it has to run as root in order to be able to change into user directories. 0 means it needs to listen on all interfaces, 110 is a standard pop3 port. After that we instruct tcpserver to use qmail's authentication engine together with vmailmgr's checkvpw, and once we have confirmed the login and password, we fire up the qmail-pop3d POP3 daemon, which does the rest. Maildir instructs qmail that we are using Maildir storage format and splogger puts the output in the system mail logs.

As with the other tcpserver line, let's stick this together into our runmail script. Now it should look like this:

-begin /usr/local/bin/runmail-
#!/bin/sh

/usr/local/bin/tcpserver -x/etc/tcp.smtp.cdb -u5002 -g1000 \ 
0 smtp /var/qmail/bin/qmail-smtpd 2>&1 \ 
| /var/qmail/bin/splogger & /usr/local/bin/tcpserver -u0 -g0 0 110 \ 
/var/qmail/bin/qmail-popup mail.dexterslab.net \ 
/usr/local/bin/checkvpw /var/qmail/bin/qmail-pop3d \ 
Maildir 2>&1 | /var/qmail/bin/splogger & 
-end /usr/local/bin/runmail-

Since we're running all tcpserver lines from the same script, we don't have to edit rc.local because it already knows to execute /usr/local/bin/runmail at boot time.

Reboot the system, or run:

root@mail:# killall tcpserver 
root@mail:# runmail
This will fire up the pop3 daemon.

Testing if everything worked

Now it's time to test if everything has been set up successfully. I will assume that your DNS settings are correct and all mail you send to dexter@dexterslab.net is going where it should be.

Fire up the tail command to watch your /var/log/mail or /var/log/maillog:

root@mail:# tail -f /var/log/maillog
Go to any other machine which doesn't use our server to send e-mail and send a message to dexter@dexterslab.net (naturally, you've been substituting this for whichever is relevant for your own system, no?).

Watch the output of your ``tail -f'' command and hope that the e-mail finds its way to you. If everything was set up correctly, then rejoice. If not, then start troubleshooting step-by-step.

If all is OK - the e-mail arrived and was stored in your user directory, then it's time to test the POP3 server. Get your favorite pop3-capable client and set it to use the following parameters:

If everything is OK, you should be able to retrieve the e-mail from your server. (And there was much rejoicing and drinking of beer).

Test the outgoing mail as well by sending mail to dexter@dexterslab.net and some remote server. Make sure they both worked. If something is astray - check your tcprules and refer to qmail, vmailmgr, and tcpserver sites for hints on what might be wrong.

Vmailmgr login usernames

As you have noticed, you use full e-mail to log in, not just your prefix. This allows vmailmgr to determine which virtual domain you are using and set everything accordingly. This is not the only login scheme; you may use any of the following three:

My experience says that most users find it far less confusing just to use their full e-mail address for logging in (otherwise they may start putting ``user:domain.com'' in their reply-to field, and such. Blech.)

Configuring Courier-IMAP

Now let's configure an IMAP server for our users. We will be using courier-imap, as it is the only one which works well with qmail, vmailmgr, and Maildir. Get it from http://www.courier-mta.org/, but don't get the whole bundle - we want just the IMAP server, without maildrop or SqWebMail (it's not as good as SquirrelMail, in my opinion).

Building and installing

Courier-imap is tricky in a way that it requires you to build it as non-root (this is overall a very good idea, too). You may untar and configure it as a regular user, or you can just follow my example and override this:

root@mail:# ./configure --disable-root-check
Courier-imap will take a while to configure and it might seem like it's going in a constant loop, but it's not. When it's done configuring, build and install it by running:
root@mail:# make && make install
This will install the courier-imap files in /usr/lib/courier-imap.

Configuring Courier-IMAP

Follow these steps to enable courier-imap with vmailmgr. First, go back to your vmailmgr-0.96-9 directory where you still have your vmailmgr distribution. Do this:

root@mail:# mv authenticate/authvmailmgr \ 
/usr/lib/courier-imap/libexec/authlib
Authvmailmgr is needed so courier-imap knows how to authenticate your virtual users. Next, go to /usr/lib/courier-imap/etc and do:
root@mail:# cp imapd.dist imapd 
root@mail:# cp imapd-ssl.dist imapd-ssl
(Configuration of imapd-ssl is not covered in this Guide, although you're welcome to investigate this on your own. Courier-imap needs imapd-ssl config file in order to be able to start.)

Now we need to edit the imapd file so it works for us. Fire up your favorite editor and look for the following lines:

MAXPERIP: The default setting is ``4'', but since we are going to be using SquirrelMail, which accesses the server from the same IP address, we want to bump it up to something more sensible, like 10 or 20. Otherwise our webmail users will have problems connecting.

AUTHMODULES: Remove all default authmodules and put just one - ``authvmailmgr''.

That's it. If you feel confident enough, you may tweak other settings, but they are not vital to the functioning of the server (unless you break something).

Starting Courier-IMAP

Courier-imap developers were nice enough to provide a convenient startup script. To start courier-imap simply run:

root@mail:# /usr/lib/courier-imap/libexec/imapd.rc start
Make sure the server is running by doing
root@mail:# ps ax | grep courier
Add ``/usr/lib/courier-imap/libexec/imapd.rc start'' line to your rc.local, or configure your sysv-init style system to use the imapd.rc file during the startup process (not covered here).

Testing your setup

Again, send a message to dexter@dexterslab.net, but this time use IMAP to connect to the server instead of POP3 when checking mail. Login and password would be the same you used last time:

If everything worked fine, rejoice. You have your e-mail system nearly ready.

Configuring Apache

Now that our e-mail system is up and running, it's time to give our clients a nice web-mail interface so they can check their e-mail whenever they are away from their computers.

I am going to advise setting up a webserver on the same machine as where your mail server is running, meaning the box we just configured. A minimalistic Apache/PHP install doesn't require a lot of resources and will not weigh down your e-mail box by much, but will give you several important advantages.

First, if you decide to limit your webmail access to HTTPS/SSL, you will not have to worry about cleartext traffic going to IMAP server and back (SquirrelMail at the time of writing doesn't support IMAPS or any alternative encryption methods). By having both httpd and courier-imap server running on the same box, you can firewall your ports to only allow access to IMAP from the local machine.

Second, you will need a webserver on that machine anyway if you want to run vmailmgr webmail front-end scripts.

Thus, my advice is to set up webmail on the same machine as the mailserver. If you choose otherwise, you may still refer to the rest of this document for hints on how to best configure SquirrelMail and your Apache server. The rest of us - let's see how we can install a webserver on this machine.

To do this, we will first need to compile and install the Apache httpd server.

Packaged stuff

Nearly every BSD and Linux distribution provides a pre-compiled version of Apache. My advise is - don't use it. With software like Apache and PHP, it's always much better to compile your own copy to make sure you only have the right stuff compiled in, and not some generic bloated version.

If you have apache installed on your system, de-install it by either using your RPM packager (rpm -e apache) or pkg_delete, or apt, or whichever your packager is. Get the latest copy of Apache-1.3 from http://httpd.apache.org/ (don't get a 2.x as it is not a production quality server at the time of writing).

Compiling and installing Apache

Untar the tar.gz file and cd into the apache-1.3.x directory. To configure and build Apache, run these commands:4

root@mail:# ./configure --prefix=/usr/local/apache \ 
--enable-module=so
root@mail:# make && make install
This will build and install apache into /usr/local/apache directory. Let's go on directly to configuring and building PHP before we get dirty with httpd.conf adaptation.

Configuring PHP

Same as before - if you have installed a pre-packaged copy of PHP on your machine - remove it and build your own version. I am yet to see a sane pre-compiled version of PHP. You can download the source code from http://www.php.net/.

Compiling and installing PHP

Untar and cd into the php-4.0.x directory. Run these commands:

root@mail:# ./configure --with-apxs=/usr/local/apache/bin/apxs
If you want SquirrelMail to talk in other languages, you will need to enable gettext support, too. Most UN*X systems come with gettext already available and you just need to compile it into the PHP by adding ``--with-gettext'' to your configuration line. This is generally a good idea, anyway, since some of your users might speak in other languages, not just English. With gettext support, the configure line will look like this:
root@mail:# ./configure --with-apxs=/usr/local/apache/bin/apxs \ 
--with-gettext
After PHP configures itself, build it like you did all others:
root@mail:# make && make install
That's it. Apache and PHP are now installed on your system.

Symlinking

For my convenience, I've always symlinked the configuration files and startup commands to where it's easy to get to them. I suggest you do the same:

root@mail:# ln -s /usr/local/apache/conf/httpd.conf /etc/httpd.conf 
root@mail:# ln -s /usr/local/apache/bin/apachectl /usr/bin/apachectl
Don't fire up the server yet. It's far from ready.

Setting up SquirrelMail

Thankfully, there are no pre-compiled versions of SquirrelMail, so you will have to get one off the web. ;) Download it from http://www.squirrelmail.org/. The latest version at the time of writing is squirrelmail-1.0.3.

Untarring and setting up directories.

I've always liked to keep my web-related documents in /home/httpd, so I will suggest the same approach. Create /home/httpd if it doesn't exist on your system and copy your squirrelmail-1.0.x.tar.gz there. Do:

root@mail:# cd /home/httpd 
root@mail:# tar xzvf squirrelmail-1.0.x.tar.gz 
root@mail:# rm squirrelmail-1.0.x.tar.gz 
root@mail:# ln -s squirrelmail-1.0.x squirrelmail 
root@mail:# cd squirrelmail
The first order of business is setting up a secure data directory away from the document root. Do this:
root@mail:# mv data /var/smdata 
root@mail:# chown -R nobody:nogroup /var/smdata 
root@mail:# chmod 0600 /var/smdata/* 
root@mail:# chmod 0700 /var/smdata
The ``nobody:nogroup'' setting is safe for most systems. If yours says something like ``no such group'', then try ``nobody:nobody'' or whatever else your system has in stock for the Apache process. To find out which user and group Apache runs as, simply do:
root@mail:# egrep '^User|^Group' /etc/httpd.conf

Configuring SquirrelMail

Using a provided perl script, this is a no-brainer.

root@mail:# cd config 
root@mail:# ./conf.pl
Settings in part 1 are up to you. In part 2 be sure to set: There shouldn't be anything in need of changing in part 3. In part 4 you need to do one thing: (If you're a non-English speaker and use charset other than iso-8859-1, change that setting, too).

That's it! You may play around with theme settings and such, if you want to. LDAP address books are not covered in this document (see SquirrelMail docs for info), and we will get to talk about plugins later.

Making Apache, PHP, and SquirrelMail work together.

Now it's up to the fun part - we get to dig apache's httpd.conf. There are several ways to do it, but if you are going to use apache just to run Squirrelmail, a very minimalistic setup is needed.

Minimalistic configuration

Open /etc/httpd.conf in your favorite editor. Don't be dismayed by the size of the file or by the abundance of comments - we will only need to change a few things as default settings will cover most anything. Let's go over the directives you need to change in the order in which they appear in our default httpd.conf installation.

This completes the minimalistic setup of the apache server!

Now run:

root@mail:# apachectl start
This should fire up your web server. Go to http://mail.dexterslab.net/ in your browser and enjoy a nice webmail front end. To log in, use the same login and password you used before.

Since we would like to run Apache at boot time, let's add this line to our rc.local:

/usr/local/apache/bin/apachectl start

Other possible configurations

Thick books have been written on the subject of Apache configuration. Naturally, most configurations are out of the scope of this guide. I can only give a few pointers.

If you are planning to use this Apache server for other stuff, you might want to bump all SquirrelMail-related stuff into VirtualHost directives so it doesn't get in the way. There are several ways to do this. For one, create a _default_ VirtualHost which will handle all requests that don't have their own ServerName allocated. The DocumentRoot for this server would be '/home/httpd/squirrelmail' and therefore anybody accessing it as mail.domain.tld will be served this default setting.

You may also set up every mail.domain.tld VirtualHost separately if you can stand the hassle. If you choose to do this, then simply point their DocumentRoot's all to the same place where your SquirrelMail installation is.

If you are planning to host regular websites for these domains and want the users to access mail in a special /mail subfolder of the www.domain.tld, you might want to create a global alias /mail/ pointing to /home/httpd/squirrelmail. This will save you a headache of creating symlinks in every documentroot.

Overall, there are many ways to configure SquirrelMail so there is only one document root for each virtual domain. You are encouraged to experiment on your own. ;)

SquirrelMail plugins

One of the greatest features of SquirrelMail is the ability to extend the basic application with additional snippets of code. You are encouraged to take a look at many plugins available for SquirrelMail and download any of them that you like. Some more useful ones are a spell-checker, address-book-taker, mail_fetch to fetch messages from other POP-boxes, and others.

Plugin installation is usually as easy as just untarring it in the plugins directory, and then running the SquirrelMail's conf.pl script, however some plugins will require you to manually edit config files or running installer scripts. Consult the plugin's documentation for more information and installation instructions.

Administration Front-end

If you are anything like me, you prefer to have a nice http front-end to ease such mundane tasks as adding and deleting users. Besides, if you are an ISP, you will probably want the domain owners to be able to administer their e-mail users without involving you. Using the system we have just configured and a nice Vmailmgr Admin plugin I wrote, it is as easy as sneezing in February.

Getting things you need

You will need two more pieces of software in addition to the ones you already have. One is a ucspi-unix package, and another one is libmcrypt. You can get them from here:

Installing Ucspi-unix

Very easy:

root@mail:# tar xzvf ucspi-unix-0.34.tar.gz 
root@mail:# cd ucspi-unix-0.34 
root@mail:# make && make install

Installing libmcrypt

Libmcrypt can give you some hard times, but it compiles without problems on every Linux platform I've tried. If you're running BSD and you're having problems compiling libmcrypt, try using your ports CVS tree instead - they sometimes provide patches which make libmcrypt compile without any problems. Otherwise, installation is very straightforward:

root@mail:# tar xzvf libmcrypt-2.4.10.tar.gz 
root@mail:# cd libmcrypt-2.4.10 
root@mail:# ./configure --prefix=/usr 
root@mail:# make && make install

Running vmailmgrd

Now it's time to run vmailmgrd. This is done by executing the following command:

root@mail:# /usr/bin/unixserver /tmp/.vmailmgrd \ 
/usr/local/sbin/vmailmgrd 2>&1 | /var/qmail/bin/splogger &
Of course, we will want to stick this into our rc.local file as well to run it at system startup:
/usr/bin/unixserver /tmp/.vmailmgrd /usr/local/sbin/vmailmgrd \ 
2>&1 | /var/qmail/bin/splogger &
That's it, vmailmgrd is up and running.

Vmailmgr Admin plugin for SquirrelMail

This plugin will allow you to administer your domains without leaving the comforts of your SquirrelMail interface. What's more important, it allows you to designate admins for each of your domains, so the owners of these domains can administer their users without involving you, the ever-busy administrator.

Since security is a very important issue here, we will make use of that libmcrypt library we have just installed. First, though, we will need to recompile PHP to enable the libmcrypt support.

Recompiling PHP4

Go back to the directory with your PHP4 source. Now run this:5

root@mail:# make distclean 
root@mail:# ./configure --with-apxs=/usr/local/apache/bin/apxs \ 
--with-gettext --with-mcrypt 
root@mail:# make 
root@mail:# make install 
root@mail:# apachectl restart
This should activate the new build of PHP with libmcrypt support. Surf to mail.dexterslab.com and make sure everything is working.

Getting and installing Vadmin

You can get the latest version of Vmailmgr Admin plugin for Squirrelmail here:

The latest version is 0.9 at the time of writing. Download the plugin, then copy it into your squirrelmail/plugins directory:
root@mail:# cp vadmin-v0.9.1.tar.gz /home/httpd/squirrelmail/plugins 
root@mail:# cd /home/httpd/squirrelmail/plugins 
root@mail:# tar xzvf vadmin-v0.9.1.tar.gz 
root@mail:# rm vadmin-v0.9.1.tar.gz 
root@mail:# cd vadmin
Vadmin provides a convenient installer to make the installation of the plugin effortless. To engage the installer, do this:
root@mail:# cd scripts 
root@mail:# ./installer.sh
The installer.sh shell script is very verbose and will guide you through the installation process giving you very detailed instructions. It would be silly to repeat them here. When the installer asks you about who should be ``elvis'', provide your login handle, which in our case is dexter@dexterslab.net.

After you have finished installing the plugin, you will need to restart your Apache server one more time so the changes can take effect:

root@mail:# apachectl restart
Now activate the vadmin plugin by running SquirrelMail's conf.pl script and choosing ``plugins''. Activate vadmin and quit the configurator. The plugin is now activated.

After this, you should move the whole 'scripts' directory somewhere where it's easy to get to them. Do this by going back to vadmin plugin directory and running the following commands:

root@mail:# mv scripts /root/vadmin-scripts 
root@mail:# cd /root/vadmin-scripts
Now we need to install a domain.

Adding domains to Vadmin

Let's add dexterslab.net to the list of domains available under vadmin. To do so, make sure you're in your vadmin-scripts directory and run the vaddomain.sh script:

root@mail:# ./vaddomain.sh dexterslab.net
It will create the necessary directories and then will ask you ``would you like to add lowly admins to this domain?'' Answer ``no'', since we're going to be the ones doing all administering. Answer ``no'' to the next question as well, since we don't want to edit cross-admins yet (we will deal with admins and cross-admins later).

Now go to http://mail.dexterslab.net/ and log into SquirrelMail. You will notice that an ``Admin'' option appeared in the menu line - vadmin has detected that you are one of the admins and gives you an option to log into the administrator interface. Go there.

You are given an option to log in. If you chose a ``USER'' option for cross-admin authentication (which is recommended for starters), then type in your mailbox password in the ``Password'' field, otherwise type in whichever is the password you chose when you were creating the dexterslab.net domain.

If you used your mailbox password when authenticating, the next screen will ask you the domain password for dexterslab.net. This is the system password you chose when you were creating this domain. Type it in and click ``Proceed''. The password will be saved on the server, but don't worry - it will be saved in an encrypted format and vadmin's security features are strong enough to make the job of hijacking the passwords rather hard.

The next screen will be the Vadmin main menu - click away to explore the convenience of this plugin. Everything should be pretty self-explanatory, plus lengthy descriptions are provided whenever something confusing comes up.

Using domain_magic.sh script

If you are adding vadmin to an existing system already running several domains configured with vmailmgr and qmail, you can run the domain_magic.sh script to make them automagically available for use with vadmin.

Adding more domains

Now let's mainstream the process of adding domains. Let's say you want to add two virtual domains to your system. For the purposes of being descriptive, I will make them be cownchikin.org and iamweasel.com.

First, let's edit our add_virt script so it calls the vadmin's scripts after creating these domains within the system. Fire up your favorite editor, go to the very bottom of the script, and right before the line where it says echo ``All done!..'', add this one:

/root/vadmin-scripts/vaddomain.sh $NEWDOM
While you're at it, modify your remove_virt script as well, doing almost the same thing: find the line at the end where it says echo ``All done!...'' and add this line right before it:
/root/vadmin-scripts/vdeldomain.sh $OLDDOM
Now let's add cownchikin.org domain:
root@mail:# add_virt cownchikin.org
When it gets to the question ``Would you like to add lowly admins for this domain?'' say ``y'' this time, because we would like ``supercow@cownchikin.org'' to be the administrator of this domain. Answering ``y'' will bring up your editor (if you didn't set it up, this will bring up vi. Don't panic, just type ``i'', then type ``supercow@cownchikin.org'', then hit ``Esc'', and type ``:wq'' + [Enter]).

The next question will be ``Would you like to add cross-admins?''. Answer ``y''. This will bring up the following screen:

Current cross-admins for 'cownchikin.org': 
---------------------- 

Handle/killall/exit:
Type in earl@cownchikin.org and hit enter. The screen will update and you will see ``earl@cownchikin.org'' in the list of cross-admins. Typing ``earl@cownchikin.org'' again will delete Earl from the list of cross-admins.

Now that you have enabled this domain on your system and within vadmin, go to http://mail.dexterslab.net/. Log in as dexter@dexterslab.net, then click ``Admin''. When you see the login screen to our vadmin interface, erase ``dexterslab.net'' where it says ``Domain'' and type in ``cownchikin.org''. Provide the domain password when it asks for it, and voila - you're in the administrative interface to our newly created domain.

Now you need to add the ``supercow'' and ``earl'' users. Select ``add new user'', and follow instructions to create the user supercow@cownchikin.org, then repeat for earl@cownchikin.org. After this, make sure you have ``mail.cownchikin.org'' domain enabled in your DNS settings and everything is ready for ``supercow@cownchikin.org'' and ``earl@cownchikin.org'' to log into SquirrelMail, click on the ``Admin'' link, and start administering the domain.

Let's finish exploring Vadmin by adding yet another domain. Type:

root@mail:# add_virt iamweasel.com
Answer ``y'' to the ``lowly admins'' question, and make weasel@iamweasel.com your lowly admin. When you are asked about cross-admins, answer ``y''. This will bring up a window looking like this:
Current cross-admins for 'iamweasel.com': 
--------------------- 

Handle/killall/exit: 
Since Earl is in both ``Cow and Chicken'' and ``I am Weasel'' cartoons on Cartoon Network, we will want him to be able to administer both cownchikin.org and iamweasel.com domains. Type in: ``earl@cownchikin.org'' to enable cross-admining of ``iamweasel.com'' for Earl.

Now go to mail.dexterslab.com, log in, click ``Admin'', erase ``dexterslab.net'', type in ``iamweasel.com'', provide password, create the ``weasel'' user, then log out, sign out, go to mail.cownchikin.org, log in as ``earl@cownchikin.org'' and click on ``Admin''. You will see that you have a choice of admining either ``cownchikin.org'' or ``iamweasel.com'' domains.

If this all confuses you, play around with vadmin and vadmin scripts to familiarize yourself with them. Cross-admins are only useful if you have any clients owning several domains and they find it a hassle to have to log out of one mailbox and log into another one just to administer their users. If you don't have any clients who own several domains, you will only need to add ``lowly admins'' and not bother with cross-admins.

Vadmin is not capable of screwing up your system, so don't be afraid to play with it. The most it will do is make a domain operational or not operational from within the vadmin plugin, so try it away. To find out what other scripts in the vadmin-scripts directory do, run this command while in that directory:

root@mail:# ./whatsthisdo.sh scriptname.sh
or just:
root@mail:# ./whatsthisdo.sh
to see descriptions for them all.

(In case you are wondering why I didn't just make a web front-end interface to adding domains, admins, and cross-admins, then the answer is - there is no really secure way of doing it from the web: too many possible exploits are available if I was to do something like this, therefore I didn't.)

Finalizing it all

Your mail system is set up. If you have encountered any problems during the install, then consult the documentation provided with the misbehaving component - it will most likely tell you whom to contact for support. If everything is running smoothly and you are happy with your system, then congratulations - you've got yourself one of the best solutions out there.

Why this is not recommended for large systems

The only reason this is not recommended for large systems is because SquirrelMail is currently not very scalable - you cannot easily run it on a server farm, since both SquirrelMail and Vadmin save their preferences onto the HDD (a trade-off for not requiring a database engine). However, if you decide not to use SquirrelMail/Vadmin, then Qmail-VmailMgr-Courier is definitely a strong enough solution to be run on high-demand servers, but this has its own set of requirements and is not covered under this guide.

Corrections and Comments

If you've found a mistake in this document which you would like to correct, or would just like to comment on something, please send a message to icon@mricon.com so I can make the correction or read your comments. You may also check my website at http://mricon.com/SM/guide/ for the latest version of this document.

Thank you and good luck! ;)

If you found this Guide useful, please let me know by executing:

root@mail:# uname -a | mail icon@mricon.com -s 'Thanks'

Sincerely, Konstantin Riabitsev, aka Mr.Icon, aka Graf.

About this document ...

Qmail-Vmailmgr-Courier-SquirrelMail Installation Guide

This document was generated using the LaTeX2HTML translator Version 2K.1beta (1.50)

Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999, Ross Moore, Mathematics Department, Macquarie University, Sydney.

The command line arguments were:
latex2html -split 0 -nonavigation -html_version 4 qvcs-guide.tex

The translation was initiated by Konstantin Riabitsev on 2001-04-09


Footnotes

... file.1
Caution: This varies from system to system and you need to consult your system's setup manuals. On some systems you will run into problems of startup scripts trying to start sendmail daemon whenever they find /usr/sbin/sendmail - doesn't matter to them if it's really a symlink to a qmail wrapper. Also, on most linux systems the rc.local file is in /etc/rc.d/ directory. Use caution and make sure your qmail starts after reboot - watch any warning messages your computer spews out during boot-up. This applies to all other places where I talk about stuff being put in /etc/rc.local.
... executing:2
General note about scripts in this Guide: In order to make the scripts look sane on a displayed/printed page, I am using backslashes to go to the next line. You can either omit the ``\'' and just continue typing without hitting ``return'' until you get to the very end of the command, or you may follow my lead and use backslashes. In this case make sure you hit ``return'' right after you typed the ``\''. What this does is it escapes the newline symbol and the system accepts the command as if it was all on one line. Most shells will show a ``>'' symbol after you hit return to denote that you may continue input.
... reflected.3
Note: This, and the remove_virt scripts may fail on a strict BSD system, which does not allow usernames longer than 8 characters and where a killall command is not available. Not to worry - since I am running a strict BSD system as well, I have modified these scripts to work on my BSD box. Get the strict versions on my web-site at http://www.mricon.com/SM/guide/.
... commands:4
Note: These instructions and configurations are only useful if you're just using Apache/PHP to run SquirrelMail and nothing else. If you are planning to provide any additional hosting on the same server, your mileage will vary. Note that for security purposes you are not encouraged to share the same server to do both hosting and web-mail, although if you know what you are doing and can provide sufficient security, there is no reason not to go for it.
... this:5
Note to (Open)BSD users: PHP-4.0.4pl1 misdetects libmcrypt and thinks you have version 2.2 instead of 2.4, which brings up errors during the build process. To work around it, download this file from http://www.mricon.com/SM/guide/config.m4 and replace the config.m4 file in ext/mcrypt directory with the patched copy. After that run ./buildconf from the source root directory to enable the changes. You should now be able to build PHP with the libmcrypt support as instructed.


Konstantin Riabitsev 2001-04-09