Setting Up Typical Configurations

---

Although all mail servers perform the same core function—transferring messages—there is a wide range of typical configurations including the general-purpose mail server, backup MX, null client, dial-up client, and smart host. This section covers what's required of these configurations and shows how they can be implemented in qmail.

General Purpose

The general-purpose mail server is the most common configuration. It's also what you'll get if you follow the installation instructions in Chapter 2, "Installing qmail." It's also a good starting point for implementing customized configurations such as the ones described in this chapter.

Functionally, the general-purpose mail server

• Accepts messages from other servers for local addresses

• Sends messages to other servers for remote addresses

• Delivers local mail to mailboxes and programs and forwards messages to local and remote addresses

qmail's modular design neatly separates the three functions: qmail-smtpd accepts messages from other servers, qmail-remote sends messages to other servers, and qmail-local delivers mail to local addresses.

Backup Mail Exchanger

The Domain Name System (DNS) provides a mechanism for specifying the mail exchangers for a domain using special MX records. These records contain the name of the mail exchanger for the given domain and a numeric preference (sometimes called distance). If multiple MX records are provided for a domain, the preference indicates the order in which they should be tried.

Background

For example, let's say Example.com is a large company. All mail sent to Example addresses is addressed to [e-mail]—including mail for individual employees as well as public addresses such as [e-mail] and [e-mail]. Because reliable mail service is important to Example, it sets up two systems to handle incoming mail: mail1.example.com and mail2.example.com. If mail1.example.com is unavailable—for example, because of hardware failure or network problems—it wants mail to be received by mail2.example.com and held there until mail1.example.com is back in service.

Implementation

To do this, Example can

1. Set up mail1.example.com as a general-purpose mail server

2. Create two MX records for example.com in the name server

3. Set up mail2.example.com as a backup mail exchanger

Step 1

Example installs qmail on mail1.example.com following the directions in Chapter 2, "Installing qmail." Because it wants this server to accept mail for [e-mail] as well as [e-mail], the company adds example.com to /var/qmail/control/rcpthosts. To have [e-mail] mail treated the same as mail to [e-mail], the company then adds example.com to /var/qmail/control/locals . To tell qmail-send to reread control/locals, it sends it a HUP signal:

 # qmailctl hup Sending HUP signal to qmail-send. # 

Because control/rcpthosts is reread each time an SMTP connection is received, there's no need to restart the qmail-smtpd service.

Step 2

Example adds MX records for example.com, such as those listed in Table 7-1.

Table 7-1: MX Records for Primary and Backup Servers

DOMAIN	EXCHANGER	PREFERENCE
example.com	mail1.example.com	10
example.com	mail2.example.com	20

Step 3

Example installs qmail on mail2.example.com following the directions in Chapter 2, "Installing qmail." Once again, it adds example.com to control/rcpthosts, but because it doesn't want [e-mail] mail to be delivered on mail2.example.com, it leaves example.com out of control/locals.

Results

With this configuration, remote sites sending mail to example.com will look up the MX records and try mail1.example.com first because its preference is a lower number. If they can't connect to mail1.example.com, they'll try to send the mail to mail2.example.com. When mail2.example.com is offered mail for [e-mail], it will accept it. Because example.com is not in control/locals, it'll immediately try to deliver it remotely. Just like the remote host that sent it the message, mail2 will look up the MX records for example.com and try to deliver it to mail1.example.com. That will most likely fail—unless mail1.example.com is back in service. Because mail2 is listed as the second MX, it won't try to deliver the message remotely to itself. The message will remain in mail2's queue until either it's successfully delivered to mail.example.com or it's been in mail2's queue for queuelifetime seconds and is returned to the sender as permanently undeliverable.

Null Client

The null client has minimal functionality as a Mail Transfer Agent (MTA). In fact, it's not even a complete MTA. Its sole function is to deliver all mail to a remote "smart" host that determines whether it's local or remote and delivers it accordingly. It's ideal for systems that should not accept mail via SMTP or store mailboxes.

Background

For example, let's say Example.com is a large company, and workstation.example.com is a user's desktop workstation. Further, user mailboxes at Example are served from imap.example.com via the Internet Mail Access Protocol (IMAP). Any mail that originates on workstation.example.com should be forwarded to mailhub.example.com, which will forward local messages to imap.example.com and deliver everything else remotely. Mail sent from a remote site to [e-mail] should be redirected via an MX record to mailhub.example.com.

Tip 

See the "Backup Mail Exchanger" section for an explanation of MX records.

Implementation

To do this, Example can

1. Configure workstation.example.com as a null client

2. Create an MX record for workstation.example.com pointing to mailhub.example.com

Step 1

Example installs qmail on workstation.example.com following the directions in Chapter 2, Installing qmail," except it

1. Skips the setup of the qmail-smtpd service because workstation will receive no incoming SMTP connections

2. Empties (but does not remove) /var/qmail/control/locals, so qmail will not deliver any mail locally

3. Puts the following entry in /var/qmail/control/smtproutes to force all outgoing mail to go to mailhub.example.com:

    :mailhub.example.com 

Step 2

Example adds an MX record like the one in Table 7-2.

Table 7-2: MX Record for a Null Client

DOMAIN	EXCHANGER	PREFERENCE
workstation.example.com	mailhub.example.com	10

Note 

qmail also supports "mini-qmail" clients, where qmail-queue is replaced with qmail-qmqpc, a QMQP client. QMQP clients and servers are covered later in "Using Quick Mail Queuing Protocol."

If all mail is addressed to [e-mail] and not [e-mail], it's not necessary to add an MX record for workstation. This will require MUAs to be configured with example.com in the user's address.

Results

The MX record directs any mail for workstation.example.com to mailhub.example.com. Because workstation receives no mail via SMTP, it runs no SMTP service.

Mail sent from workstation is delivered remotely because control/locals is empty, and because control/smtproutes has a wildcard entry, all outgoing mail goes through mailhub.example.com.

Dial-up Client

In many cases, a typical general-purpose mail server configuration can work as-is over a dial-up connection, but there are a couple situations that benefit by additional customization: part-time connectivity and using the Internet Service Provider's (ISP's) mail hub as a smart host.

qmail was designed for well-connected hosts, so it assumes it's always connected to the Internet. For clients with dial-on-demand connectivity, this means that attempts to send remote mail will bring the connection up. For other clients with part-time connectivity it means that attempts to send remote mail will fail if the connection is currently down. The serialmail package (see Appendix B, "Related Packages") includes a utility called maildirsmtp that can be used to implement a queue of outgoing messages that can be flushed when the Internet connection is brought up.

Some mail servers refuse to accept connections from dial-up clients in an ineffective attempt to reduce junk mail. Because of this, using the ISP's mail hub as a smart host can help dial-up clients get their mail delivered—especially if their ISP identifies dial-up clients using the Dial-Up List (DUL) DNS blacklist (see Chapter 8, "Controlling Junk Mail").

Background

For example, dialup.example.net is a dial-up client of the ISP Example.net. The domain owner wants remote mail to be queued until the connection is active and then flushed to mail.example.net, which delivers the messages locally or remotely as necessary. qmail, daemontools, ucspi-tcp, and serialmail are already installed. The Internet Protocol (IP) address of mail.example.net is 192.168.1.20.

Implementation

To do this, the domain owner can

1. Use a wildcard virtual domain to redirect all remote mail to a local alias

2. Use the dot-qmail file for the alias to save the messages in a maildir mailbox

3. Use maildirsmtp to flush the queue to mail.example.net

Step 1

First, the domain owner stops qmail while he's doing the reconfiguration:

 # qmailctl stop Stopping qmail. . .   qmail-smtpd   qmail-send # 

Next, he creates /var/qmail/control/virtualdomains with the following entry:

 :alias-outgoing 

Step 2

He creates /var/qmail/alias/.qmail-outgoing-default with the following entry:

 /var/qmail/spool/ 

Next, he creates the spool maildir:

 # maildirmake /var/qmail/spool # chown -r alias /var/qmail/spool # 

Now he restarts qmail:

 # qmailctl start Starting qmail # 

Step 3

He adds the following command to a script that's run automatically each time the dial-up (Point-to-Point Protocol, or PPP) interface is activated. On Red Hat Linux, for example, the script is /sbin/ifup-local:

 setlock /var/lock/outspool maildirsmtp /var/qmail/spool alias-outgoing- \ 192.168.1.20 'hostname' 

The setlock command ensures that only one copy of maildirsmtp is processing /var/qmail/spool at a time by locking the file outspool. The maildirsmtp command processes the messages in /var/qmail/spool/, stripping alias-outgoing- from the Delivered-To field to re-create the original recipient address. It then connects to 192.168.1.20 (mail.example.net), identifies itself with the host name supplied by hostname, and forwards the messages.

Tip 

The same maildirsmtp command can be run periodically while the connection is active to flush mail sent after the connection became active.

Result

The wildcard control/virtualdomains entry intercepts all outgoing mail and delivers it to the spool maildir. When the dial-up connection is activated, the ifup-local script invokes maildirsmtp to forward the spooled mail to mail.example.net.

Smart Host

A smart host, also known as a mail hub or relay, is basically a mail router. It accepts mail from local systems for local and remote recipients and from remote systems for local recipients—but it may not deliver any of the "local" mail locally, instead routing it to one or more local mailbox servers.

Background

For example, the company Example.com wants mail.example.com to accept mail for [e-mail] and forward it to its mailbox server, exchange.example.com. It also wants mail.example.com to accept messages from the company's entire network, 192.168.x.x, for all recipients and forward them to exchange.example.com if they're for local recipients or to the appropriate remote site otherwise.

Implementation

To do this, Example can

1. Configure mail.example.com as a general-purpose mail server

2. Create an MX record for example.com pointing to mail.example.com

3. Create a control/smtproutes entry to forward local mail to exchange.example.com

4. Implement selective relaying to accept mail for all destinations from hosts on the 196.168 network

Step 1

Example follows the directions in Chapter 2, "Installing qmail," and then adds the following line to /var/qmail/control/rcpthosts:

 example.com 

Step 2

Example creates a DNS MX entry like the one in Table 7-3.

Table 7-3: MX Record for a Smart Host

DOMAIN	EXCHANGER	PREFERENCE
example.com	mail.example.com	10

Step 3

Example adds the following entry to /var/qmail/control/smtproutes:

 example.com:exchange.example.com 

Step 4

Example adds the following entry to /etc/tcp.smtp:

 192.168.:allow,RELAYCLIENT="" 

and rebuilds the binary SMTP access control database, /etc/tcp.smtp.cdb:

 # qmailctl cdb Reloaded /etc/tcp.smtp. # 

Results

Mail sent to [e-mail] goes to mail.example.com because of the MX record. Mail from all hosts to mail.example.com for [e-mail] is accepted because example.com is in control/rcpthosts. Mail received from hosts on the 192.168 network is accepted regardless of the destination because RELAYCLIENT is set by tcpserver.

Mail for [e-mail] is forwarded to exchange.example.com because of the control/smtproutes entry and because example.com is not listed in control/locals.

Mailbox Server

A mailbox server is a system that accepts mail for local users, stores it in mail-boxes, and provides access to the mailboxes via Mail User Agents (MUAs) running on the server itself or through the Post Office Protocol version 3 (POP3) or IMAP to remote MUAs.

Background

Example wants to set up email.example.com as a mailbox server. The company wants its users to be able to access their mail through POP3 and IMAP, and it wants email.example.com to accept mail from all example.com systems (192.168.x.x network), regardless of the destination.

Implementation

To do this, Example can

1. Configure email.example.com as a general-purpose mail server

2. Install qmail-pop3d and Courier-IMAP

3. Create users and initialize their mailboxes

4. Implement selective relaying to accept mail for all destinations from hosts on the 196.168.x.x network

Step 1

Example follows the directions in Chapter 2, "Installing qmail." Because both qmail-pop3d and Courier-IMAP work with maildir mailboxes only, it sets /var/qmail/control/defaultdelivery to this:

 ./Maildir/ 

Step 2

Example follows the directions in Chapter 10, "Serving Mailboxes," to install qmail-pop3d and Courier-IMAP.

Step 3

The operating system on email.example.com provides an adduser command that copies the contents of the /etc/skel "skeleton" directory to the home directory of each new user created, changing the owner from root to the new user's user-name. This means that creating an empty maildir in /etc/skel will automatically set up each new user with an empty maildir. To create the skeleton maildir, it does this:

 # maildirmake /etc/skel/Maildir # 

Now the company creates new user accounts by running adduser, either manually or using a script.

Step 4

Example adds the following entry to /etc/tcp.smtp:

 192.168.:allow,RELAYCLIENT="" 

and rebuilds the binary SMTP access control database, /etc/tcp.smtp.cdb:

 # qmailctl cdb Reloaded /etc/tcp.smtp. # 

Results

Users created on email.example.com automatically get mailboxes because of the maildir in the skeleton directory, and control/defaultdelivery directs their mail to that maildir.

The POP3 and IMAP servers provide remote access to the user's mailboxes.

Users can relay mail through email.example.com because tcpserver sets RELAYCLIENT for all connections from the 192.168.x.x network.

---