Virtual Domains and qmail
The program qmail is a secure and reliable replacement for sendmail; it was written by Dan Bernstein at the University of Illinois at Chicago. I was attracted to it for several reasons, the most important being that it runs under Linux.
qmail is substantially more secure than sendmail. The system is partitioned into several modules, minimizing the amount of code which runs as root. The /var/spool/mail directory is gone; incoming mail for a user is stored in the user's home directory, eliminating a nagging security hole. qmail gives you control over which mail you accept. You can selectively allow other hosts to use your system as a relay, blocking out all others.
qmail supports mailing lists with automated subscriptions, and these lists can be configured and maintained entirely by the user. No intervention is required on the part of the system administrator to create a new list.
qmail's performance is stellar. Dan Bernstein cites Red Hat Software as an example. Red Hat was running sendmail 8.7 on a 48MB Pentium and found their daily load of 70,000 messages was beginning to overwhelm the system. They switched to qmail on a 16MB 486/66, and their mail hub is now running fine, even on the less powerful hardware.
The reason I began looking into qmail as an alternative to sendmail is the fact that qmail supported e-mail for virtual domains correctly long before sendmail did. Those of you running several virtual domains on a single Linux host can rejoice. With qmail, the e-mail names you select for your virtual domains come from per-virtual-domain name spaces, rather than a single host-wide name space. This means you can have e-mail names like firstname.lastname@example.org and email@example.com simultaneously.
The only problem we have had with qmail is the fact that its outgoing queue uses inode numbers in its database; this means the queue cannot be backed up on one machine and restored to another. When we have a disk failure, we must recreate an empty qmail queue directory rather than restoring from backup.
The fact that qmail is not sendmail implies some complications when installing add-on e-mail packages like majordomo. In general there are patched versions of these packages available for qmail.
The qmail sources are available at ftp://koobera.math.uic.edu/www/qmail.html and a lot of useful information is available at http://www.qmail.org/. Compilation and installation of qmail is straightforward. Those who balked at the sendmail.cf file will be pleasantly surprised at qmail's configuration. Everything is human readable and easy to understand. Some claim that sendmail.cf is human readable, but I would argue that point.
Once you have qmail configured and operational, you can start adding virtual domains. The rest of this article deals with virtual domains under qmail. All file and path names assume the default qmail installation.
Set up the new virtual domain normally. Many of you will have already done this to support the virtual domain with other services like Apache httpd. Make sure there is an MX record in DNS to point mail for the virtual domain to the host running qmail.
Create a master user ID and home directory for the new domain. The master user is just a user who will control all mail for your virtual domain. I generally create a user ID for each virtual domain which the administrators of that domain can use to upload the content for their web site. qmail can use the same user ID.
Add a line to /var/qmail/control/virtualdomains for the new domain, directing mail for that domain to the user created above. If the domain is abc.com and the user is abc, an appropriate line would be:
Add abc.com to /var/qmail/rcpthosts to tell qmail you're willing to accept mail addressed to abc.com. Ensure abc.com does not appear in /var/qmail/control/locals/.
Once mail is directed to a user, it is controlled through a series of .qmail-xxx files in that user's home directory. Create the file ~abc/.qmail-default, to indicate user abc is willing to accept all mail directed to the abc.com domain.
Restart qmail and e-mail for all users at abc.com, i.e., firstname.lastname@example.org, email@example.com, etc. will now be received by the local user abc. I suspect this is not precisely what you had in mind, so read on.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Client-Side Performance
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Peppermint 7 Released
- Sony Settles in Linux Battle
- Libarchive Security Flaw Discovered
- Maru OS Brings Debian to Your Phone
- The Giant Zero, Part 0.x
- Git 2.9 Released
- Snappy Moves to New Platforms
- Profiles and RC Files
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide