Konstantin Riabitsev
icon@mricon.com
Version 0.99.1: April 9, 2k1
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.
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
This shows latest versions at the time of writing. If newer versions are available, you should probably get them.
Setting up Qmail is rather trivial, but here are most basic steps you need to take.
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:
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:
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.
For the sake of providing examples I am going to assume that your hostname is ``mail.dexterslab.net''.
Go to /var/qmail/control directory:
Since most systems cannot function without sendmail, qmail provides a sendmail wrapper. To activate it do this:
Go to /var/qmail/boot, find the file called ``home'' and move it to /var/qmail/rc.
After the machine is done booting, make sure your qmail is running by executing:
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.
No sweat, as always. Simply do:
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:
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
(You may wish to use other editor, not vi, if you are not comfortable with it).
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:
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:
Check to see if you have done everything correctly by doing this:
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:
Get the latest version of vmailmgr from http://www.vmailmgr.org/. At the time of writing it is vmailmgr-0.96-9.tar.gz.
Untar the distribution and cd into the vmailmgr-0.96-9 directory. Now configure and build it:
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.
Now, here is a script I am using to add virtual domains:
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.
Removing domains is also easy with a similar script. Here is what I am using:
Put this file with the other and set permissions to execute.
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.
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.
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:
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.
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.
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.
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:
As with the other tcpserver line, let's stick this together into our runmail script. Now it should look like this:
/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-
Reboot the system, or run:
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:
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.
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.)
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).
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:
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:
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).
Courier-imap developers were nice enough to provide a convenient startup script. To start courier-imap simply run:
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.
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.
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).
Untar the tar.gz file and cd into the apache-1.3.x directory. To configure and build Apache, run these commands:4
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/.
Untar and cd into the php-4.0.x directory. Run these commands:
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:
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.
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:
Using a provided perl script, this is a no-brainer.
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.
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.
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:
Since we would like to run Apache at boot time, let's add this line to our rc.local:
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. ;)
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.
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.
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:
Very easy:
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:
Now it's time to run vmailmgrd. This is done by executing the following command:
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.
Go back to the directory with your PHP4 source. Now run this:5
You can get the latest version of Vmailmgr Admin plugin for Squirrelmail here:
After you have finished installing the plugin, you will need to restart your Apache server one more time so the changes can take effect:
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:
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:
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.
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.
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:
The next question will be ``Would you like to add cross-admins?''. Answer ``y''. This will bring up the following screen:
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:
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:
(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.)
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.
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.
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.
If you found this Guide useful, please let me know by executing:
Sincerely, Konstantin Riabitsev, aka Mr.Icon, aka Graf.
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