Running qmail under Gentoo Linux by Kris Kelley NOTE: This guide was written for use with qmail ebuild 1.03-r13. The current stable qmail ebuild is 1.03-r15. Several other ebuilds mentioned in this documentation also have been updated since the last revision. Unfortunately, I do not expect to update this guide again any time soon, if ever. I no longer work as an email system administrator, I no longer have qmail running on any of my systems, and my time away from work is now devoted to other projects. The good news is that the Gentoo website now has Gentoo-specific documentation about qmail and its related software packages. I now recommend using the official documentation, as well as the Gentoo forums and the qmail mailing list. This guide will remain available at its original URL (http://www.skunkworx.org/guides/QmailOnGentoo.txt), for reference. Also, for anybody who might wish to adapt and/or update this guide, I am making it available under the Creative Commons Attribution-ShareAlike 2.0 license; details are available at the license website (http://creativecommons.org/licenses/by-sa/2.0/). I would like to thank everyone who provided constructive criticism and words of encouragement while I was actively maintaining this guide. I still believe qmail is the best email server program out there, for any platform, and I hope the qmail and Gentoo communities continue to thrive. Introduction This document gives instructions on how to install, configure, and run qmail on a system running Gentoo Linux. I originally wrote this after I could not find any qmail documentation specific to Gentoo, despite Gentoo offering packages (or "ebuilds", to use Gentoo's terminology) for qmail and related software. You are probably not reading this if you are not familiar with Gentoo Linux, but just in case, Gentoo is a relatively new distribution that aims at striking a compromise between the convenience and compatibility of a linux installation based on ready-made software packages, and the power and configurability of a linux installation built from source. For more details, visit Gentoo's website (http://www.gentoo.org). Gentoo's promise of being able to tailor software exactly to a system's specifications, while at the same time having a package manager easily keep track of it all, is what attracted me to this distribution, to say nothing of the recommendations I received from friends and coworkers. You are probably also not reading this if you have not heard of qmail, but to be thorough, Daniel J. Bernstein's qmail is an email server software package, providing the same general functionality of packages like Sendmail or ssmtp. qmail is undebatably the most secure email server software available for Unix-compatible operating systems, and I would argue that it is the most secure email server software period. qmail also provides plenty of configurability, enough to suit the needs of almost any email-related task. The fact that qmail has not had an official release since 1997, and yet continues to grow in popularity without a single security alert, is testimony of its quality. qmail is not for the faint of heart, however. Even with a versatile package manager like Gentoo's Portage, qmail requires some manual intervention, not to mention firm knowledge of what you are doing, to run optimally. Things to Know before Starting These instructions were written using Gentoo Linux 1.4, installed following the distributors' instructions, and the qmail ebuild provided by Gentoo through its package manager, Portage. As of this writing, the recommended Gentoo ebuild for qmail is 1.03-r13. There may be instructions here that are specific to these versions; in particular, earlier versions of the qmail ebuild are significantly different from 1.03-r13, and I do not recommend trying to use this guide with them. Also, Gentoo and Portage are highly customizable, and experienced Gentoo users who have heavily tweaked their systems may find these instructions completely off base. The qmail ebuild is modeled on the process prescribed by "Life with qmail" (LWQ, http://www.lifewithqmail.org), written by Dave Sill. LWQ is *required* reading; the instructions given here mostly highlight the differences between LWQ and the qmail ebuild, as well as the manual steps needed to complete qmail's installation and configuration. Gentoo's qmail ebuild includes several patches to the original source code. These patches fix minor, non-critical bugs, and also provide additional features not present in the author's distribution of qmail 1.03, such as the ability to encrypt SMTP sessions with SSL, and the ability to authenticate sessions with passwords unique to each user on your system. (NOTE: The current version of LWQ makes use of a package called netqmail. netqmail 1.05 is a patched version of qmail 1.03. Bugs and incompatibilities fixed by netqmail 1.05 are also fixed by Gentoo's 1.03-r13 ebuild for qmail, and therefore LWQ is still an essential source of information, even for Gentoo users.) IMPORTANT: qmail, as well as any software package written in the C programming language, relies on a package called glibc to provide the basic C function libraries. As of this writing, Gentoo's recommended glibc ebuild is version 2.3.2-r9. Because of an old coding method that is no longer supported by the authors of glibc, all qmail ebuilds older than 1.03-r10 (as well as the unpatched source code for qmail 1.03) ARE NOT COMPATIBLE with any ebuilds based on glibc 2.3.2! To ensure smooth installation, make sure you are using the latest unmasked ebuilds of qmail and all software packages qmail depends on (including daemontools, ucspi-tcp, checkpassword, cmd5checkpw, dot-forward, and queue-fix; more information about these packages is provided below.) Part One - Configuring Gentoo to Allow qmail's Installation Before you can install qmail, you may need to configure Gentoo to allow you to do so. This requires knowing a few things about Gentoo and Portage. One of Portage's features is the ability to keep track of "virtual" packages. Virtual packages are not specific software packages, but are definitions that can be matched by any Gentoo ebuild claiming to do so. When you install (or "merge") an ebuild that matches the definition of a virtual package, Portage considers that virtual package present on your system. Gentoo keeps a list of default ebuilds it will use to satisfy virtual package needs. An ebuild from this list is merged whenever the associated virtual package is requested and a matching ebuild is not already present. Many of these ebuilds are added to the system during Gentoo's initial set-up. Much of Gentoo's behavior is governed by a set of configuration files collectively known as a "profile." Included in a profile is the default list for satisfying virtual package requirements. Regardless of what profile you use, you can look at the associated files in /etc/make.profile. Editing these files is not a good idea, unless you are planning on building your own profiles for distribution. Besides the default list supplied by a profile, Gentoo also keeps a list of virtual packages actually present on your system, and the ebuilds that represent those virtual packages. Gentoo keeps this list in the file /var/cache/edb/virtuals. Whenever you merge an ebuild that satisfies the requirements for a virtual package, that virtual package's entry is created or updated in /var/cache/edb/virtuals. Gentoo ebuilds can be designed to block their own installation if they would conflict with other software already present on the system. These blocks can be based on virtual packages as well as specific ebuilds. Gentoo controls the presence of an email server (or, more accurately, a "mail transfer agent") with the virtual package "virtual/mta". Gentoo's qmail ebuild is a virtual/mta package, but of course it is not the only one. If you followed all instructions for installing Gentoo, ssmtp will be present on your system, and will be listed in /var/cache/edb/virtuals. Because most systems really only need one mail transfer agent, the ebuilds for ssmtp, qmail, and other MTAs will block installation if a virtual/mta package is already present. So, if ssmtp or some other virtual/mta package is already installed on your system, you will need to allow qmail to be installed on your system. There are two good ways of doing this: 1. Uninstall the virtual/mta package currently on your system. Any configuration you may have performed to run the current MTA on your system, such as having it start automatically during system boot, will need to be undone prior to removal. 2. Edit the qmail ebuild script to remove the virtual/mta block. For version 1.03-r13, the ebuild script is usually kept at /usr/portage/net-mail/qmail-1.03-r13.ebuild. The edit involves finding the two lines that look like this: RDEPEND="!virtual/mta virtual/glibc and replacing them with this one line: RDEPEND="virtual/glibc #2 is the recommended choice, as other components of your system may complain about the sudden lack of a virtual/mta package. It is safe to keep your current MTA while installing and configuring qmail, as long as you do not try to run both MTAs at the same time. Once you have removed any currently installed virtual/mta packages, or have modified the qmail ebuild script, you will be ready to install qmail. IMPORTANT: Before you can emerge qmail and related ebuilds, you must also have the right system users and groups on your system. You will need users named "alias", "qmaild", "qmaill", "qmailq", "qmailr", and "qmails", and groups named "nofiles" and "qmail". Also, the alias user's home directory must be set to /var/qmail/alias. Normally this is all taken care of during Gentoo's installation, specifically, when the baselayout package is emerged. If you have since edited your users and groups files, removing entries you believed were unnecessary, make sure you have the right users and groups before proceeding! Part Two - Installing and Configuring qmail and Related Software Thanks to Portage and the "emerge" command, all of the software required for running qmail is installed with a single command. However, keep in mind that the authors of Gentoo recommend you always run emerge with the "pretend" flag prior to installing any new packages, so that you know for certain what is about to be installed on your system. # emerge -p qmail These are the packages that I would merge... (NOTE: The 1.03-r13 qmail ebuild uses one USE flag, "ssl". You must set this USE flag, either in /etc/make.conf or in your shell's USE environment variable, if you want to install qmail with encrypted SMTP support. More information about encrypted SMTP is in appendix B.5) Depending on what you already have available, you will see a number of ebuilds that Portage would merge along with qmail. Most likely you will see "ucspi-tcp", "daemontools", "dot-forward", "checkpassword", "cmd5checkpw", and "queue-fix" in this list. Except for "cmd5checkpw" and "queue-fix", these are additional tools written by Bernstein, designed to provide a stable, easily configurable environment for qmail. "ucspi-tcp" and "daemontools" in particular are required packages for a qmail installation that conforms to LWQ, and Gentoo's default configuration appropriately defines qmail as dependent on these packages. (NOTE: "cmd5checkpw" is used to offer authenticated SMTP; see appendix B.3 for more information. "queue-fix" is used to initially create the qmail queue, that is, the folders qmail uses to temporarily store email that is being processed; it can also be used to repair or recreate the queue when needed.) Once you are satisfied in knowing what is going to be added to your system, run emerge again without the "pretend" flag. # emerge qmail When this command finishes, the system will be almost ready. Portage not only installs qmail and all related software, but also performs a number of necessary system configurations, and installs several scripts documented in LWQ. Gentoo's qmail ebuild includes an option that allows for some additional automatic configuration. In fact, this extra configuration will be enough for qmail to run securely and effectively on many systems. However, while I recommend taking advantage of this option to prevent any security checkpoints from being accidentally overlooked, this feature should not be considered a substitute for following the rest of this guide, especially if qmail is to be used in a production environment. To perform the additional automatic configuration, run this command: # ebuild /var/db/pkg/net-mail/qmail-1.03-r13/qmail-1.03-r13.ebuild config If run, the above command will look up the machine's fully qualified domain name, and set up qmail to treat as local any email bound for this name specifically. For example, if the fully qualified domain name is machine.example.com, qmail will process for local delivery any email bound for addresses ending in "@machine.example.com" (but not "@example.com"). qmail will also be set up to allow SMTP (mail transport) connections from anywhere. For local connections, all email will be accepted, and any email not destined for local delivery will be directed (or "relayed") to the appropriate destination. For all other connections, only email destined for local delivery will be accepted. These configurations may not be exactly what you want, so continue reading to learn how to configure qmail to suit your needs. (NOTE: Running the above ebuild command will also generate a self-signed SSL certificate for use with encrypted SMTP. See appendix B.5 for more information. If you plan on making use of encrypted SMTP, first edit /var/qmail/control/servercert.cnf, particularly the values in the "req_dn" section, before running the above ebuild command. This will ensure your new SSL certificate contains the correct information for your system. Remember that qmail needs to be emerged with the "ssl" USE flag for encrypted SMTP to work.) From this point, follow LWQ starting with section 2.7. Refer to the instructions below for Gentoo-specific notes related to each section. 2.7. daemontools has already been installed by Portage by this point, however, the daemontools ebuild does not change /etc/inittab. Instead, the ebuild provides an rc script for svscan in /etc/init.d. To ensure that svscan will start during system boot, use Gentoo's rc-update command to link the svscan rc script within the appropriate runlevel directory or directories. If you plan on running qmail from the default runlevel, enter this command: rc-update add svscan default Note that starting svscan from an rc script does not protect it from unexpected termination. If you would like to take advantage of init's ability to recreate processes that have died, do *not* use Gentoo's rc script for svscan. Instead, edit /etc/inittab, adding this line: SV:12345:respawn:/usr/bin/svscanboot Note that the ebuild uses a different directory for daemontools' executables than the author's original package. 2.8.1. The qmail ebuild supplies a /var/qmail/rc script and a /var/qmail/control/defaultdelivery control file similar to the ones given in LWQ. In the Gentoo ebuild versions, comments are allowed in /var/qmail/control/defaultdelivery; any line starting with "#" will be ignored. The ebuild configures qmail to use maildirs, however, note that the name of each user's maildir directory is slightly different than that given in LWQ (".maildir/" instead of "Maildir/"). 2.8.2.1. The qmail ebuild does not provide the /var/qmail/bin/qmailctl script. Instead, a script named qmail-control is created and placed in /var/qmail/bin. qmail-control allows for qmail's services to be stopped and started, and for the locals and virtualdomains control files (see below) to be reread. qmailctl offers the same functionality and more, providing an easy, convenient alternative to remembering several different commands. So, while creating /var/qmail/bin/qmailctl as documented in this section of LWQ is not necessary, it is highly recommended. The comments for Red Hat Linux's chkconfig tool are not needed. PATH does not have to include /usr/local/bin or /usr/local/sbin; these directories are empty on a typical Gentoo system. 2.8.2.2. Gentoo's qmail ebuild creates all the necessary supervise scripts that are documented in this section of LWQ. /var/qmail/supervise/qmail-send/log/run and /var/qmail/supervise/qmail-smtpd/log/run, as created by the qmail ebuild, are slightly different than those given by LWQ. The difference enables the multilog program to rotate the log files of qmail-send and qmail-smtpd when they reach approximately 2.5MB in size, instead of the default 100kB. (NOTE: See http://cr.yp.to/daemontools/multilog.html for more information about how multilog maintains log files.) /var/qmail/supervise/qmail-smtpd/run as provided by the ebuild is very different from the one presented in LWQ. Generally speaking, version 1.03-r13 of the qmail ebuild was designed so that qmail's functionality could be changed entirely with configuration files, removing the need for manipulating any qmail-related scripts or programs. In particular, the Gentoo version of /var/qmail/supervise/qmail-smtpd/run relies on the Gentoo-specific control files /var/qmail/control/conf-common and /var/qmail/control/conf-smtpd for configuring qmail's SMTP service. Editing these files is not essential for basic qmail and SMTP functionality, and is also not recommended for those installing qmail for the first time. Once you are comfortable with how qmail operates, and would like to take advantage of features like authenticated SMTP or spam blacklisting, you can edit these configuration files to suit your needs. See appendix B for more information about editing the /var/qmail/control/conf-common and /var/qmail/control/conf-smtpd configuration files. Creating the concurrencyincoming control file is optional. You can use this file for setting the maximum number of concurrent connections allowed, or instead edit the appropriate section of /var/qmail/control/conf-common. If neither action is taken, qmail will limit the number of possible concurrent incoming SMTP connections to 40. All log files under /var/log already exist by this point, as does the /service directory. You will need to create the symbolic links within the /service directory. Note that qmail will *not* start automatically after these links are created, *unless* svscan is running (see the notes above for LWQ section 2.7). 2.8.2.3. This section is not necessary if you used the optional "emerge" command for extra automatic configuration, described above. Otherwise, perform the steps in this section as given. Note that this section expects you to have created the /var/qmail/bin/qmailctl script given in LWQ section 2.8.2.1. 2.8.3. If you haven't done so already, now is a good time to remove any other virtual/mta packages from your system. For example, you can run these commands to remove ssmtp: emerge -C mailbase emerge -C ssmtp Note that you should first undo any configuration you may have performed to run another email server on your system, such as having it start automatically during system boot. If qmail services began running while another virtual/mta package was still being utilized, stop qmail as documented in this step. You can use the qmail-control script to do so if you decided not to create qmailctl. The "sendmail" symbolic links will already exist by this point. 2.8.4. The qmail ebuild creates all of the .qmail files under /var/qmail/alias mentioned in this section. The .qmail files are empty, which means any email bound for the affected addresses will be directed to user alias's maildir. If this is not the behavior you want, follow LWQ's instructions for editing these files. 2.8.5. Again, svscan should be running before you try to start (or restart) qmail using qmailctl (or qmail-control). See the notes for LWQ section 2.7 above. 2.9. Perform these steps as given to test your new installation. Now follow the instructions given in LWQ section 3 to fully configure qmail to your liking. If you performed the optional configuration discussed above, a number of control files documented in LWQ section 3.1 will already exist by this point: /var/qmail/control/me /var/qmail/control/defaultdomain /var/qmail/control/plusdomain /var/qmail/control/locals /var/qmail/control/rcpthosts Each of these files will contain a single line, the fully qualified domain name of the machine. Gentoo's installation of qmail allows for several extra control files in addition to those documented in LWQ section 3.1 They are described below: Control Default Used by Description badmailto (none) qmail-smtpd blacklisted To addresses badrcptto (none) qmail-smtpd blacklisted To addresses conf-common as given various configuration common to all of qmail's network services conf-pop3d as given qmail-pop3d configuration specific to qmail's POP3 service conf-qmqpd as given qmail-qmqpd configuration specific to qmail's QMQP service conf-qmtpd as given qmail-qmtpd configuration specific to qmail's QMTP service conf-smtpd as given qmail-smtpd configuration specific to qmail's SMTP service morebadrcptto (none) qmail-smtpd more blacklisted To addresses Also, regular expressions can be used in badmailfrom and badmailto. (NOTE: Yes, badmailto and badrcptto provide essentially the same functionality. That's what happens when a lot of different patches are used to make a program as functional and configurable as possible.) (NOTE: QMTP, the Quick Mail Transfer Protocol, is an alternative to SMTP, designed by qmail's author. QMTP is not compatible with SMTP, nor is it widely used across the Internet. If you wish to read more about QMTP, have a look at LWQ section 5.11, and also Daniel Bernstien's documentation for QMTP (http://cr.yp.to/proto/qmtp.txt). More information about QMTP will be in a future revision of this guide.) (NOTE: QMQP, the Quick Mail Queueing Protocol, was designed by qmail's author to allow multiple servers running qmail to pool their messages into a single queue on a centralized server. The outlying servers run a special configuration of qmail called "mini-qmail" and use QMQP to send their messages to the central server. Bernstien has documentation for mini-qmail (http://cr.yp.to/qmail/mini.html) and QMQP (http://cr.yp.to/proto/qmqp.html). More information about these features will be in a future revision of this guide.) (NOTE: The optional configuration discussed above will also create files "clientcert.pem", "rsa512.pem", and "servercert.pem" in /var/qmail/control. These files are your self-signed SSL certificate and are necessary for encrypted SMTP; more information about them is provided in appendix B.5. They can be safely ignored if you do not plan on using encrypted SMTP, or if you did not emerge qmail with the "ssl" USE flag enabled.) Part Three - After qmail Is Up and Running Some tips for smooth operation and extended functionality. * By default, Portage's "config file protection" extends to qmail's configuration directory, /var/qmail/control. This feature prevents qmail's configuration from being blindly overwritten by any future upgrades or removals. Run "emerge -h config" for more information. * Assuming you kept the default delivery instructions provided by Gentoo (/var/qmail/control/defaultdelivery), each user on your system will need a maildir named ".maildir" in his or her home directory. See LWQ section 4.1.3 for more information. * Refer any users on your system to LWQ section 4 for information on how to exert control over their incoming email. * LWQ section 5.2.1 provides information on how to install and configure the POP3 server that comes with qmail. If you decide to use this POP3 server (qmail-pop3d), read through the steps given in LWQ section 5.2.1.2. If the standard checkpassword program meets your needs, then steps 1 through 6 will already have been performed by the Gentoo qmail ebuild by this point. The supervise scripts set up by the ebuild for POP3 service are different from those given in LWQ, and the differences are similar to those described above for qmail-smtpd. /var/qmail/supervise/qmail-pop3d/run is designed to read configuration from /var/qmail/control/conf-common and /var/qmail/control/conf-pop3d. Modifying these configuration files is not necessary for standard POP3 functionality, and not recommended for those running POP3 service for the first time. Once you are familiar with how qmail's POP3 service operates, you can change these files to take advantage of features like alternative password checking programs, and POP-before-SMTP authentication. Appendix B provides more information about how to edit the configuration files, if you decide to do so. When you are ready to offer POP3 service, run the following command to allow svscan to automatically start and supervise the qmail-pop3d process: ln -s /var/qmail/supervise/qmail-pop3d /service (NOTE: Gentoo used to provide a separate ebuild called qmail-pop3d that would install the necessary scripts for running qmail's POP3 server. The current qmail ebuild provides the same functionality, therefore the qmail-pop3d ebuild is no longer necessary.) If you created the /var/qmail/bin/qmailctl script discussed in LWQ section 2.8.2.1, follow steps 7 through 12 to add features related to qmail-pop3d. If you decided to keep the /var/qmail/bin/qmail-control script instead, it is already capable of starting and stopping qmail-pop3d. If svscan is currently running, POP3 service should now be available. * Portage merges the dot-forward ebuild along with qmail. dot-forward allows people to create delivery instructions using Sendmail's format. Custom delivery instructions for Sendmail are usually kept in files named ".forward", hence this package's name. See LWQ appendix B.1 for more information. Conclusion - Any Questions? Your qmail server should now be ready for action. However, you may still have some questions or concerns. If you are using Gentoo without many customizations, and you have a concern about qmail's installation as performed by Portage, contact the maintainers of Gentoo, as they wish to be notified of any problems with their ebuilds. Their policy is to investigate the problem, and then notify the original software authors themselves if they determine the cause lies there. Visit Gentoo's bug page (http://bugs.gentoo.org) for more information. If you have successfully installed qmail, but now you have a question about its performance and/or your configuration, the qmail mailing list is the place to ask experienced qmail users for information. However, please keep in mind these are people giving of their free time, and they are very tired of reading the same questions over and over. I cannot emphasize this enough: READ THE DOCUMENTATION and, if appropriate, CHECK YOUR LOGS before asking a question on the list. LWQ, the qmail man pages, the web pages maintained by qmail's author at http://cr.yp.to, and especially the qmail mailing list archives (http://www.ornl.gov/cts/archives/mailing-lists/qmail/) are all excellent sources of information, and many list veterans consider all of these to be required reading. Should you decide a question to the list is necessary, list veteran Charles Cazabon has written "12 Steps to qmail List Bliss" (http://www.qcc.ca/~charlesc/writings/12-steps-to-qmail-list-bliss.html), detailing what every list veteran would like to see happen when somebody has a question about qmail. If you have a question or comment about this guide in particular, feel free to email me at skunkworx@kingwoodcable.com. Appendix A - The qmail Program Chain This section briefly describes how the various qmail programs are set up, and how they interact with one another to provide qmail's services. Understanding these interactions is essential if you plan on modifying your qmail installation to take advantage of additional features, such as those described in appendix B. This section does not go into much detail, and is also somewhat specific to the way qmail is installed and configured on Gentoo systems. For a better and more general understanding of why and how these programs interact the way they do, you are encouraged to read the referenced documentation. The svscan init script (/etc/init.d/svscan) is used to start all of qmail's services. First, an svscan (http://cr.yp.to/daemontools/svscan.html) process is created. For every symbolic link created within the /service directory, svscan then creates and monitors two supervise (http://cr.yp.to/daemontools/supervise.html) processes. The second supervise process creates and monitors a multilog (http://cr.yp.to/daemontools/multilog.html) process, which will feed the output of the first supervise process into a log file. The first supervise process's activity depends on the service. For qmail-send, supervise executes and monitors the /var/qmail/rc script. By default, this script in turn executes qmail-start, which in turn creates all the processes in charge of processing qmail's message queue. These processes include qmail-send, qmail-clean, qmail-lspawn, and qmail-rspawn. Man pages are available for these four programs, and for qmail-start. For qmail-smtpd, supervise creates and monitors a softlimit (http://cr.yp.to/daemontools/softlimit.html) process, designed to limit the use of system resources and prevent runaway processes. softlimit in turn creates a tcpserver (http://cr.yp.to/ucspi-tcp/tcpserver.html) process, configured to listen for SMTP connections. For every SMTP connection received, tcpserver creates a qmail-smtpd process to handle that connection. A man page is available for qmail-smtpd. For qmail-pop3d, supervise creates and monitors a softlimit process, which in turn creates a tcpserver process configured to listen for POP3 connections. For every POP3 connection received, tcpserver creates a qmail-popup process to handle that connection. qmail-popup displays to the connecting client a POP3 greeting, then prompts for a login name and password. qmail-popup then executes a password checking program to verify the login name and password. If the login name and password are valid, the password checking program will then create a qmail-pop3d process to further handle that connection; otherwise, the password checking program will exit, causing the connection to be dropped. Man pages are available for qmail-popup and qmail-pop3d. (NOTE: If you followed the instructions for adding svscanboot to /etc/inittab, svscanboot (http://cr.yp.to/daemontools/svscanboot.html) will be executed during system boot, which in turn will create the svscan process.) Appendix B.1 - qmail Network Service Configuration This section explains the environment variables that can be defined in /var/qmail/control/conf-common, /var/qmail/control/conf-smtpd, and /var/qmail/control/conf-pop3d. The values of these variables are in turn used by /var/qmail/supervise/qmail-smtpd/run and /var/qmail/supervise/qmail-pop3d/run. This section assumes an understanding of how the various programs interact to provide qmail's services; see appendix A for an overview. The configuration files provide default definitions for most of these variables. The defaults will be enough for many qmail users' needs. Appendices B.2 through B.5 provide examples of how the configuration files can be changed to enable certain features in qmail. I *strongly* recommend leaving these files alone until you are confident about what you are doing. /var/qmail/control/conf-common provides definitions that affect all of qmail's network services. /var/qmail/control/conf-smtpd and /var/qmail/control/conf-pop3d provide definitions that will affect only SMTP and POP3 services, respectively. Except where noted, these environment variables can be defined in conf-common or in a specific network service's configuration file. A definition in a specific network service's configuration file will override any definition of that variable in conf-common, unless the previous definition is incorporated into the new definition. * MAXCONN The maximum number of concurrent connections that tcpserver will allow. If unset, tcpserver will use its internal default of 40. Normally, this value is read from /var/qmail/control/concurrencyincoming. * NOFILESGID The GID of the system group that will run the tcpserver processes in charge of providing qmail-related network services. * QMAIL_CONTROLDIR The directory for qmail's control files. This will almost always be /var/qmail/control. This variable is also defined in an /etc/env.d configuration file, so defining it again is really not necessary. * QMAIL_POP3_CHECKPASSWORD Specific to POP3. This variable defines the program that will be executed to verify a POP3 login's name and password. It is assumed that this program provides the standard checkpassword interface, described at http://cr.yp.to/checkpwd/interface.html, and further assumed that this program can execute qmail-pop3d when a login name and password have been successfully verified. * QMAIL_POP3_POP3HOST Specific to POP3. This variable defines the name of the machine that qmail's POP3 service will identify as its host. By default, this is read from /var/qmail/control/me. * QMAIL_POP3_POSTAUTH Specific to POP3. Normally, the password checking program defined by QMAIL_POP3_CHECKPASSWORD will execute qmail-pop3d when a login name and password have been successfully verified. If this variable is defined, the password checking program will instead execute the program or string of programs given by this variable. It is assumed that qmail-pop3d and its command-line arguments can be passed as the final command-line arguments of this program chain. * QMAIL_POP3_PREAUTH Specific to POP3. After accepting a POP3 connection, tcpserver will normally execute qmail-popup to provide the initial POP3 greeting and password prompt to the connecting client. If this variable is defined, tcpserver will instead execute the program or string of programs given by this variable. It is assumed that qmail-popup and its command-line arguments can be passed as the final command-line arguments of this program chain. * QMAIL_SMTP_POST Specific to SMTP. This variable provides command-line arguments to execute qmail-smtpd with. * QMAIL_SMTP_PRE Specific to SMTP. After accepting an SMTP connection, tcpserver will normally execute qmail-smtpd to provide SMTP service to the connecting client. If this variable is defined, tcpserver will instead execute the program or string of programs given by this variable. It is assumed that that qmail-smtpd and its command-line arguments can be passed as the final command-line arguments to this program chain. * QMAIL_TCPSERVER_PRE Normally, softlimit will execute tcpserver. If this variable is defined, softlimit will instead execute the program or string of programs given by this variable. It is assumed that tcpserver and its command-line arguments can be passed as the final command-line arguments to this program chain. * QMAILDUID The UID of the system user that will run the tcpserver processes in charge of providing qmail-related network services. * SOFTLIMIT_OPTS Command-line arguments to execute softlimit with. See http://cr.yp.to/daemontools/softlimit.html for more information about the options available. * TCPSERVER_HOST The IP address tcpserver will listen for connections on. * TCPSERVER_OPTS Command-line arguments to execute tcpserver with, in addition to -x, -c, -u and -g. See http://cr.yp.to/ucspi-tcp/tcpserver.html for more information about the options available. * TCPSERVER_PORT The specific port of the IP address defined by TCPSERVER_HOST that tcpserver will listen for connections on. This can be defined in the configuration file specific to each network service, however, conf-common as installed by the qmail ebuild will set the value of this variable equal to that of the SERVICE environment variable. SERVICE is defined by each network service's supervise script, "smtp" for SMTP, "pop3" for POP3, and so on. For this to work, these services need to be defined with port numbers in /etc/services. * QMAILQUEUE Normally, qmail pipes all messages through a program called "qmail-queue." qmail-queue's task is to place each message into qmail's message queue, where later it will be picked up by qmail-send for further processing and delivery. This environment variable, which by default is not set, allows another program to take the place of qmail-queue, providing the opportunity for additional processing on each message before it is placed in the queue. See http://www.qmail.org/qqrbl for one example of a replacement qmail-queue program. Note: You better know what you are doing if you wish to take advantage of this feature. If you do not replace qmail-queue with a program that provides at least the same functionality, you will break your qmail installation! Appendix B.2 - Authenticated SMTP Gentoo's installation of qmail allows SMTP sessions to be authenticated with the ESMTP AUTH command. This permits you to restrict relaying priveleges to people who have correct user names and passwords, instead of people who connect from certain IP addresses (the two methods can also be used together). The ESMTP AUTH command was designed to support different methods of password verification, and this implementation provides the three most popular methods: PLAIN, LOGIN, and CRAM-MD5. This makes qmail's authentication feature compatible with most email clients currently available. To enable authenticated SMTP, the QMAIL_SMTP_POST environment variable in the conf-smtpd control file needs to be defined with three arguments. The man page for qmail-smtpd explains what these arguments should be: a hostname, a password checking program, and an additional subprogram. The hostname should be the fully qualified domain name of your email server; it is used to generate CRAM-MD5 "challenges." The password checking program must conform to the checkpassword standard defined at http://cr.yp.to/checkpwd/interface.html, with one additional requirement: If the password checking program is to support CRAM-MD5, the program must be able to handle both unencrypted passwords and MD5-encrypted challenges and responses. The subprogram is executed by the password checking program if password verification was successful; usually set to /bin/true, the subprogram must return "true" when exiting. (NOTE: checkpassword and other compatible programs are also used by qmail to authenticate POP3 sessions, as explained earlier in this guide. When authenticating POP3 sessions, the subprogram argument is necessary because, after verifying a user's name and password, the password checking program is expected to execute qmail-pop3d. In the case of authenticated SMTP, the subprogram really doesn't serve any purpose, which is why /bin/true is normally used.) The default conf-smtpd control file has configuration that, when uncommented, will enable authenticated SMTP, using cmd5checkpw as the password checking program. cmd5checkpw keeps a list of allowed user names and passwords in /etc/poppasswd; see the cmd5checkpw man page for more details. If cmd5checkpw suits your needs, uncomment the four environment variable definitions in the "SMTP-AUTH" section of conf-smtpd. Be sure to set up /etc/poppasswd as instructed by the cmd5checkpw man page for authentication to work properly. Other password checking programs can be used. For example, checkpassword uses /etc/passwd and/or /etc/shadow, enabling system users to use authenticated SMTP. To use checkpassword, edit conf-smtpd, uncommenting the four environment variable definitions mentioned in the above paragraph. Then, change the line defining QMAIL_SMTP_CHECKPASSWORD to look like this: QMAIL_SMTP_CHECKPASSWORD="/bin/checkpassword" Remember to restart qmail afterward. One advantage of using checkpassword over cmd5checkpw is that passwords do not have to be stored in an unencrypted format on the server. This is counterbalanced by the disadvantage of checkpassword not supporting CRAM-MD5; consequently, LOGIN or PLAIN must be used, which means passwords have to be sent unencrypted across the network. (NOTE: You may need to change the permissions of checkpassword for it to work properly in this case. The program must be setuid root, otherwise authentication will fail. Run "chmod 6755 /bin/checkpassword" to give checkpassword the proper permissions. Keep in mind that setting programs to be setuid root is generally a bad idea, and you may wish to look into other password checking programs instead.) (NOTE: If you plan on providing POP3 and/or IMAP service, you may want to use the same authentication data across all email services. If you plan on providing POP3 service using qmail's POP3 server, you can use the same password checking program for both POP3 and authenticated SMTP. Have a look at the conf-pop3d control file, and make sure the QMAIL_POP3_CHECKPASSWORD environment variable is set to your liking.) For more information about authenticated SMTP and how it works, Erwin Hoffman has written a tutorial, available at http://www.fehcom.de/qmail/smtpauth.html. Appendix B.3 - Outbound Authenticated SMTP qmail can also be instructed to use authenticated SMTP when relaying email to other servers. This is useful when you plan on routing all your email through another email server, such as the one provided by your Internet service provider, and that server requires authentication. If you have qmail configured to deliver all email to another server, then you should have a single line in the smtproutes control file that looks similar to this: :mail.your-isp.com To enable outbound authenticated SMTP, modify that line to include a username and password, both of which should be encoded in base64: :mail.your-isp.com This feature was patched into qmail. The patch's original author, Jay Soffian, has documentation at http://www.soffian.org/downloads/qmail/qmail-remote-auth-patch-doc.txt, which includes some Perl commands to help with base64 encodings. There are also web-based base64 encoders available. For the security-conscious, keep in mind that base64 encoding is not the same as encrypting, and anybody who can see your smtproutes control file can learn your passwords. Also, this feature uses LOGIN for authentication, which means the remote server must support LOGIN, and which also means your passwords will be sent unencrypted across the network. Appendix B.4 - POP-before-SMTP An alternative to authenticated SMTP is POP-before-SMTP. When a POP-before-SMTP system is in place, any user that first checks his or her incoming email with POP3 is then permitted, for a period of time, to relay outgoing email through the server. POP-before-SMTP implementations accomplish this by remembering POP3 clients' IP addresses, and looking for each SMTP client's IP address in that list, granting relay permission if the address is listed. The list is periodically cleaned of old IP addresses, ensuring relay permission is not granted for longer than necessary. While not as secure as authenticated SMTP, POP-before-SMTP is a good solution that supports all email clients, including those that cannot use authenticated SMTP. POP-before-SMTP requires additional software, specifically, a program that will actually maintain the list of IP addresses permitted to relay. Portage offers relay-ctrl, written by Bruce Guenter, for this purpose. Emerge this package with the following commands: # emerge -p relay-ctrl These are the packages that I would merge... # emerge relay-ctrl After emerge finishes, edit the conf-smtpd and conf-pop3d control files. The default installation already includes the necessary configuration in each of these files, commented out. In conf-smtpd, uncomment the first two environment variable definitions in the section that begins with, "If you are interested in providing POP or IMAP before SMTP..." In conf-pop3d, uncomment the two environment variable defitions in the section for POP3 before SMTP. After saving the changes, remember to restart qmail. POP-before-SMTP should now work. (NOTE: This appendix assumes you are providing POP3 service, and that you are using qmail-pop3d to do so. With relay-ctrl, it is possible to use a different POP3 server and still provide POP-before-SMTP. It is even possible to provide "IMAP-before-SMTP" instead, using Courier IMAP. These examples are beyond the scope of this guide, however, there is documentation for relay-ctrl at http://untroubled.org/relay-ctrl/ and for Courier IMAP at http://www.inter7.com/courierimap.html, as well as notes about enabling IMAP-before-SMTP in the default installation of conf-smtpd.) Appendix B.5 - Encrypted SMTP Ordinarily, SMTP communications are "in the clear," with no encryption. This means anybody who can eavesdrop on your network activity can monitor your email traffic, snooping messages, sender and recipient addresses, and perhaps even SMTP authentication user names and passwords. Consequently, an extention to the SMTP protocol was drafted, providing email servers with the ability to encrypt SMTP sessions by using the ESMTP STARTTLS command. Gentoo's qmail ebuild allows encryption to be used on both incoming and outgoing SMTP connections. To enable encrypted SMTP, first make sure that you emerged qmail with the "ssl" USE flag enabled. Next, you must have an SSL server certificate in place. If you ran the ebuild command for extra automatic configuration, described in Part Two above, then a self-signed certificate is already in place. If you did not run the ebuild command, you can generate a self-signed certificate by first editing /var/qmail/control/servercert.cnf, filling in information specific to your server, and then running /var/qmail/bin/mkservercert. When the certificate generation process finishes (using either command), three new files will appear in /var/qmail/control: servercert.pem, the server's new self-signed certificate, used for incoming SMTP connections; clientcert.pem, which can be a separate certificate used for outgoing SMTP connections, but which by default is the same as servercert.pem; and rsa512.pem, the private code-key used to decrypt incoming SMTP traffic. Restart qmail after creating your certificate. At this point, any client that supports the ESMTP STARTTLS command will be able to request an encrypted SMTP session; also, the server will automatically request an encrypted SMTP session when connecting to any remote host that boasts ESMTP STARTTLS support. The server is ready to go. Further configuration is possible, providing, among other features, the ability to refuse outgoing email to remote hosts that do not support encryption, and the ability to accept email from ecrypting clients that otherwise would have been rejected. For more information, visit the web page for Frederik Vermeulen's original patch for qmail (http://inoa.net/qmail-tls/). Note that self-signed certificates may be rejected by some servers as insecure or untrustworthy. You may want to have a certificate signed by a mutually trusted Certificate Authority instead. (NOTE: The process of getting an SSL certificate issued by a Certificate Authority is really beyond the scope of this guide, however, I plan to have more information in a future revision.) Also, be aware that encrypting your server's SMTP traffic does not guarantee that your email is safe from prying eyes. Email messages are sometimes relayed through multiple servers, one or more of which may not support encryption. Also, email that has made it to its final destination is usually stored unencrypted, making it possible for other users or administrators on that server to read it. For more complete email security, you may want to consider using an email client that supports encrypting each email message before it is sent. Of course, this will require that the recipient be able to decrypt the message. Further information would be beyond the scope of this guide, but you can visit the web pages of email clients that support message encryption, such as Mutt (http://www.mutt.org/), and the web pages of general-use encryption software, such as GnuPG (http://www.gnupg.org/). Appendix C - Patches Warning: Lots of technical jargon ahead. This section describes the patches that are applied to the qmail 1.03 source code by the qmail 1.03-r13 ebuild. I should mention that many qmail veterans consider some of these patches to be unnecessary for general use, suggesting that one should use as pristine a copy of qmail as possible, applying only those patches that are known to be needed. If you are handy at writing and modifying ebuild scripts, you may want to consider editing qmail's ebuild script to remove patches that do not apply to you. Of course, qmail has been found to run just fine with these patches, and they do provide features many find useful, and fix bugs many find annoying or inconvenient. Buyer beware, however: The author of qmail makes no guarantees about its security beyond his original code. Buyer beware again: Removing patches may result in unexpected behavior if the configuration files and scripts are not modified appropriately. * qregex-starttls-2way-auth (http://www.arda.homeunix.net/store/qmail/) This patch combines several patches into one, providing several extentions to qmail's functionality. This patch provides the extra configuration file /var/qmail/control/badmailto, and enables the use of regular expressions to be used in /var/qmail/control/badmailto and /var/qmail/control/badmailfrom. For more information, visit the original patch's web page (http://www.unixpimps.org/software/qregex/). This patch also provides the ESMTP AUTH command, enabling qmail to require authorization before accepting messages for processing. For more information, visit the original patch's web page (http://members.elysium.pl/brush/qmail-smtpd-auth/). See appendix B.2 for details on how to make use of this feature. This patch also gives qmail the ability to use the ESMTP AUTH command when connecting to other SMTP servers. See appendix B.3 for more details on outbound authenticated SMTP. Finally, this patch enables TLS/SSL support for encrypted SMTP sessions. See appendix B.5 for details on how to make use of this feature. Patch written by Andrew St. Jean, based on the work of "unixpimps.org," Krzysztof Dabrowski, "Mrs. Brisby," Frederik Vermeulen, and Neal Groothuis. * smtp-auth-close3 According to the qmail 1.03-r13 ebuild, this patch "fixes a problem when utilizing morercpthosts" together with ESMTP AUTH. * qmailqueue (http://www.qmail.org/qmailqueue-patch) This patch provides qmail with the ability to replace qmail-queue with other programs. See appendix B.1 for more details. Patch written by Bruce Guenter. * big-todo (http://qmail.null.dk/big-todo.103.patch) qmail was designed to be able to handle large numbers of email messages without a significant slow-down. One way it accomplishes this is by splitting its queue into several different directories. Many of these directories are in turn split into subdirectories, ensuring that no single folder becomes unnecessarily large. When a message is first accepted by qmail for processing, it is placed in the "todo" directory. Normally, this directory is not split into subdirectories like certain queue directories are. This means that if a large number of messages enters the system before qmail has a chance to process them all, the todo directory could become quite large, introducing a lag into the system. This patch enables the todo directory to be split into subdirectories, helping to prevent a sudden influx of email from being a problem. Patch written by Russel Nelson, with some modification by Bruce Guenter. * qmail-1.03-qmtpc (http://www.qmail.org/qmail-1.03-qmtpc.patch) This patch allows qmail to send email to other servers using QMTP instead of SMTP. More information about QMTP will be in a future revision of this guide. Patch written by Russel Nelson. * qmail-103 (http://www.ckdhr.com/ckd/qmail-103.patch) Unpatched qmail will have trouble sending email to domains whose DNS servers send oversized answers to DNS queries. This patch resolves this issue. Patch written by Christopher K. Davis. * qmail-local-tabs Unpatched qmail, when handling .qmail files whose first lines are nothing but tabs, has the potential to access an array out of range, an error more commonly known as a memory or buffer overflow. This bug is generally considered to be minor, because qmail by this point is running as the owner of the .qmail file and will never run as root, and also because qmail's documentation states that a .qmail file should not start with an empty line. Nonetheless, this is a bug, and this patch fixes it. * qmail-link-sync (http://www.jedi.claranet.fr/qmail-link-sync.patch) qmail assumes that certain file commands are synchronous, that is, the commands will not report a successful finish until the file has actually been written to disk (as opposed to residing in a cache to be written later). While this assumption is true for some Unix-compatible operating systems and the file systems they use, it is not true for many flavors of linux and its file systems. The consequence is that a disruption of service, such as a power outage, could result in email being lost. This patch works around this issue by forcing file synchronization to take place after these commands. Patch written by Frank Denis. * big-concurrency Unpatched qmail has an inherent maximum concurrency limit of 255. In other words, the highest number of concurrent local deliveries and concurrent remote deliveries that can take place is 255 each. This patch allows those limits to be as high as 65,000, though the qmail 1.03-r13 ebuild sets a new maximum limit of 500 for each. Patch written by Johannes Erdfelt. * qmail-0.0.0.0 0.0.0.0 is considered to be a self-referencing IP address, similar to 127.0.0.1 (though the semantics of each are not quite the same). Unpatched qmail does not treat 0.0.0.0 as a local IP address; this patch resolves that issue. Patch written by Scott Gifford. * errno This patch fixes the code compatibility issue that prevents qmail 1.03 from compiling or running properly against versions of glibc 2.3.2 and newer. * sendmail-flagf (http://david.acz.org/software/sendmail-flagf.patch) qmail's sendmail wrapper does not support the "-f" option that the real sendmail does. This patch provides that feature. Patch written by David Phillips. * qmail-maildir++ (http://www.shupp.org/patches/qmail-maildir++.patch) Sam Varshavshik, the author of Courier and Courier IMAP, authored an extention to the maildir format called maildir++. Among other things, maildir++ provides for multiple email subdirectories, and quota support. This patch enables qmail to make use of maildir++, allowing greater compatibility between qmail and packages supporting maildir++, such as Courier IMAP and vpopmail. Patch written by Bill Shupp. * maildir-quota-fix This patch fixes a typo in the above patch. * qmail-date-localtime (ftp://ftp.nlc.net.au/pub/unix/mail/qmail/qmail-date-localtime.patch) Whenever qmail needs to generate a timestamp, such as when adding a "Date:" header to an email message, it uses Greenwich Mean Time (GMT) timestamps. Most email clients know how to convert GMT into the local time zone, but some do not. This patch enables qmail to generate timestamps in the local timezone instead. * qmail-limit-bounce-size (http://www.qmail.org/www.jedi.claranet.fr/qmail-bounce.patch) Normally, qmail will include a copy of the entire original message for the original sender when generating a bounce message. This patch allows for a new control file, "bouncemaxbytes", that states the maximum size a bounce message can be. Any bounce message that would go over this limit will be truncated. * qmail-smtpd-esmtp-size-gentoo This patch provides support for the ESMTP SIZE command, allowing qmail to reject messages deemed too large before they are sent, instead of after. * qmail-smtpd-relay-reject.gentoo Some email servers allow their users to relay messages to non-local addresses by creating a new email address that appears to be local. To illustrate, an email server local to example.com could be instructed to deliver a message to user@anotherexample.com by sending it a message addressed to user%anotherexample.com@example.com. qmail by default does NOT support this trick, as it can be easily abused by spammers who are aware of it. However, according to some programs that test the integrity of email servers, qmail APPEARS to support this trick, because it does not reject up front any email messages addressed to local domains; instead, it later bounces any messages that are not destined for valid addresses, such as those with "%" or other extraneous characters. Because these broken testing programs do not check to see if their messages were actually delivered, many qmail servers have unfortunately been incorrectly blacklisted. This patch works around this issue by enabling qmail to reject up front any recipient addresses that use "%" and other such characters. * qmail-gentoo-1.03-r12-badrcptto-morebadrcptto-accdias.diff This patch provides for two new control files, "badrcptto" and "morebadrcptto". They work similarly to badmailfrom, rejecting up front any messages bound for addresses that appear in either of these files. Patch originally written by Ward Vandewege, later modified. * qmail-popupnofd2close (http://www.dataloss.nl/software/patches/) This patch allows checkpassword and similar programs to log error messages to stderr. Patch written by peter(at)dataloss.nl. * qmail-1.03-reread-concurrency.2 (http://js.hu/package/qmail/) This patch enables qmail to reread control files concurrencylocal and concurrencyremote when the qmail-send process receives a HUP signal. Normally qmail has to be restarted for these files to be reread. Patch written by Julian Severn-nek. * 08-capa.diff (http://www.mcmilk.de/qmail/dl/djb-qmail/patches/) This patch provides the POP3 CAPA command, allowing POP3 clients to get a list of all POP3 commands provided by qmail-pop3d. Patch written by Tino Reichardt. Appendix D - Additional Software This is a collection of additional software packages, many of which are available through Portage, that are useful for managing qmail and extending its functionality. * Courier IMAP (http://www.inter7.com/vpopmail) (ebuild available) An IMAP server that supports the maildir format, and therefore integrates very well with qmail. * qlogtools (http://untroubled.org/qlogtools) (ebuild available) A set of programs designed to analyze qmail's logs for monitoring and statistics gathering. * qmail-scanner (http://qmail-scanner.sourceforge.net/) (ebuild available) A multi-purpose email scanner specifically designed to work with qmail, useful for combatting viruses, spam, and even unwanted file attachments. qmail-scanner can be configured with its own set of rules, and can also work with other popular email tools such as SpamAssassin (http://spamassassin.org, ebuild available), F-Prot (http://www.f-prot.com, ebuild available), and many commercial virus scanners available for linux. * qmailanalog (http://cr.yp.to/qmailanalog.html) (ebuild available) Another set of tools for analyzing qmail's logs, written by the author of qmail. * vpopmail (http://www.inter7.com/vpopmail) (ebuild available) A collection of programs designed to make the creation and management of virtual users and multiple email domains relatively fast and painless. Acknowledgements Thanks to Dave Sill for excellent qmail documentation in the form of "Life with qmail" and 'The qmail Handbook'. Thanks to Charles Cazabon for invaluable help through the qmail mailing list. Thanks to Daniel J. Bernstein for qmail itself. Thanks to the authors and contributors of Gentoo for creating an excellent linux distribution. Guide Revision History 3/20/03 - First release. 3/21/03 - Corrected the statement about Gentoo's scripts not providing a limit on the number of simultaneous incoming SMTP connections. There is always a limit, even if it is not explicitly set. Thanks to Dave Sill for pointing out this typo. 4/17/03 - Added a note about the incompatibility between qmail 1.03 and glibc 2.3.2, and also fixed some grammatical and formatting mistakes. glibc 2.3.1 must be used to compile qmail and related packages. 5/13/03 - Added comments about the qmail ebuild's option for extra automatic configuration, and cleaned up some wording here and there. 5/15/03 - Added comments about the qmail-sumo and qmail-pop3d ebuilds. Thanks to Tridib Biswas for pointing these out to me. 7/20/03 - Updated the guide to reflect recent releases of qmail and related ebuilds for Gentoo. 11/30/03 - Rewrote several sections in part one to more accurately explain Portage's system of virtual packages and package blocking; added appendices, which will be further fleshed out in the next update; cleaned up some wording here and there. This update is incomplete, pending a new version of the guide to be based on qmail ebuild 1.03-r13. 12/29/03 - Updated the guide to reflect qmail ebuild 1.03-r13. Reorganized the appendices. This update is also incomplete, as many sections in the appendices still need to be written. 12/30/03 - Corrected a statement concerning the Gentoo ebuild's initial configuration of qmail. By default, qmail will accept SMTP connections from anywhere, not just from local IP addresses. 2/8/04 - Removed information about the qmail-sumo ebuild, which is no longer in Portage. Updated information about "Life with qmail," which is now based on netqmail 1.05. Updated information about glibc; the latest stable ebuild is now 2.3.2-r9. Added a note about making sure the correct system users and groups are in place before emerging qmail. Added information about the qmail-control script installed by the qmail ebuild. Reorganized the appendices again, and wrote sections concerning authenticated SMTP, outbound authenticated SMTP, POP-before-SMTP, and additional qmail-related software. The section on encrypted SMTP still needs to be written. Cleaned up wording and formatting in various places. 2/20/04 - Wrote the section on encrypted SMTP. Cleaned up wording in various places. 2/22/04 - Fixed a typo in the section for encrypted SMTP. "servercert.pem" was mentioned where "servercert.cnf" should have been named. 6/5/05 - Added the note that I am no longer actively maintaining this guide.