Relaying

---

What is relaying? It's when an MTA accepts a message that is not for a local address or from a local sender. MTAs perform two basic functions: SMTP server and SMTP client. In the server function, they typically accept mail from other systems on the network that's intended for a local user. In the client function, they do the opposite: They accept mail from local users and deliver it to other systems on the network.

In the early days of the Internet, it was common for MTAs to be configured as open relays: promiscuous servers that would accept mail from anyone, for anyone—including non-local users. This is no longer recommended because unscrupulous junk mailers use open relays to deliver unsolicited bulk e-mail (UBE) or unsolicited commercial e-mail (UCE). Rather than sending their advertisements directly from their own servers, they use open relays as unwitting accomplices. The purpose is twofold: First, it offloads most of the work of delivering the UBE onto the relay, and, more importantly, it allows the spammer to hide the origin of the messages, circumventing mechanisms intended to block messages from known abusers.

Most MTAs now are configured to either completely disable relaying or to only allow certain trusted users or systems to use them as a relay.

How qmail Controls Relaying

We know that relaying occurs when an MTA accepts a message not for a local address or from a local sender, so relay control occurs at the point when new messages enter the system. Obviously, a message injected by running a shell command on the system, such as qmail-inject or the sendmail wrapper, is from a local user, so qmail does no relay control in this case. That leaves the case of messages injected via SMTP.

When an SMTP client sends a message, qmail-smtpd looks at the domain names of the recipients, which are specified with the SMTP RCPT command. If the domain specified is listed in /var/qmail/control/rcpthosts, the message is accepted. If it's not listed in rcpthosts, the message is rejected with the following message:

 553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1) 

qmail includes a mechanism for overriding rcpthosts for certain clients, which is discussed in the "Allowing Selective Relaying" section, but in a basic installation qmail-smtpd makes no exceptions: Even connections from the local host are subjected to the rcpthosts check. This has been confusing for some new qmail administrators who receive the previous message when sending a message using an agent that injects via SMTP and they naively interpret it to mean that rcpthosts contains a list of domains to which the system will let them send mail. The correct action is not to add remote domains to rcpthosts, but to configure the local host as a selective relay, as outlined in the "Allowing Selective Relaying" section.

Note 

qmail-smtpd does not look at the envelope sender address to determine if a message is from a local user. That's because SMTP is unauthenticated, and SMTP clients can specify any envelope sender address they want—even one on your system. This is known as spoofing.

Disabling Relaying

If you followed the directions in the INSTALL file for installing qmail, relaying is turned off by default. This is accomplished by populating the file /var/qmail/control/rcpthosts with the fully qualified domain names listed in locals and virtualdomains. If you followed the directions in Chapter 2, "Installing qmail," relaying is allowed for SMTP connections originating from the local host only.

When you update locals or virtualdomains, be sure to update rcpthosts as well, so qmail-smtpd will know which domains are local.

Caution 

Never remove /var/qmail/control/rcpthosts on a system accessible from the Internet: It will make your system an open relay that will be abused by mass mailers as soon as it's discovered.

Allowing Selective Relaying

There are a few ways to allow only certain users or systems to use your mail system as a relay. The simplest method is to set up a file listing the hosts trusted not to abuse the relaying privilege. More sophisticated mechanisms that relay on authentication of the host or client are provided though add-ons and source-code modifications.

Host-Based Relaying

Most single-user and small workgroup servers can disable relaying completely, but if you have to support a distributed user community, you'll need a way to allow your users, and only your users, to use your system as a relay. This is accomplished by using tcpserver to set the RELAYCLIENT environment variable, which tells qmail-smtpd to override the rcpthosts file.

If you follow the installation instructions in Chapter 2, selective relaying will be enabled by default. To give a client relay access, add an entry to /etc/tcp.smtp like this:

 IP address of client:allow,RELAYCLIENT="" 

Caution 

There should be no blank spaces anywhere on this line.

For example, to allow the host with the IP address 192.168.1.5 to relay, add the entry

 192.168.1.5:allow,RELAYCLIENT="" 

You can use wildcards. To match 192.168.1.anything:

 192.168.1.:allow,RELAYCLIENT="" 

You can also specify domain names:

 =client.example.net:allow,RELAYCLIENT="" 

Complete documentation for the access control file is on the Web (http://cr.yp.to/ucspi-tcp.html).

Once you've updated /etc/tcp.smtp, rebuild the binary SMTP access data-base used by tcpserver by doing this:

 qmailctl cdb 

which executes the following commands:

 tcprules /etc/tcp.smtp.cdb /etc/tcp.smtp.tmp < /etc/tcp.smtp chmod 644 /etc/tcp.smtp* 

Authenticated Relaying

Host-based selective relaying is fine if you know in advance from which hosts your clients will be sending mail. But what do you do if they have dynamic host names or roam from one ISP to another and still need to be able to send mail? Sure, they could reconfigure their MUAs to send mail through the relay provided by the ISP they're connected through, but that's inconvenient.

The two most common solutions are to require users to authenticate via POP3 or IMAP before allowing relaying, or to use authenticated SMTP.

Relay-After-POP, Relay-After-IMAP

The concept is simple: When a user successfully logs into your POP3 or IMAP server, you add their current IP address to the SMTP access control file. After a reasonable but short period, you purge their address from the access control file as a precaution against abuse by the next user assigned that IP address. Since MUAs periodically reconnect to check for new mail, the user retains relay access as long as they're connected.

Thanks to qmail's modular architecture, the implementation is also pretty straightforward. Bruce Guenter's relay-ctrl package consists of relay-ctrl-allow, which adds a host to the access database, and relay-ctrl-age, which removes inactive hosts after 15 minutes. It works with qmail-pop3d and courier-imap. Complete documentation is available (http://untroubled.org/relay-ctrl/). Other relay-after-POP3/IMAP packages are also listed on the Web (http://www.qmail.org/).

Tip 

Some mailers attempt to send mail before checking for new mail. Users of these MUAs should be instructed to disable this feature or expect the first attempt to send messages to fail occasionally.

The main advantage of relay-after-POP/IMAP mechanisms is that they're simple and they don't require any support in the MUA: If the MUA talks SMTP and either POP3 or IMAP, it will work with relay-after-POP/IMAP.

Authenticated SMTP

Internet RFC 2554 (http://www.ietf.org/rfc/rfc2554.txt) added the AUTH command to SMTP. MTAs supporting the AUTH extension—used with MUAs that also support it—allow the user to authenticate directly with the SMTP server. The AUTH extension is an implementation of the Simple Authentication and Security Layer (SASL) specified in RFC 2222. qmail does not include AUTH support, but a programmer who goes by the name "Mrs. Brisby" wrote a modification for qmail-smtpd.c. Another programmer, Krzysztof Dabrowski, enhanced Mrs. Brisby's patch, adding support for additional authentication methods. See http://www.elysium.pl/ members/brush/qmail-smtpd-auth/ for more information, including general information about SMTP AUTH and the MTAs and MUAs that support it.

Another approach to authenticated SMTP is the STARTTLS extension added by RFC 2487. This mechanism allows servers and clients to authenticate each other using cryptographic certificates. After a client sends the STARTTLS SMTP command, the remainder of the SMTP session is encrypted—which is useful for protecting the privacy of messages sent over the Internet. Programmer Frederik Vermeulen has implemented STARTTLS for qmail in the form of a source-code patch (http://www.esat.kuleuven.ac.be/~vermeule/qmail/tls.patch). This patch is still considered experimental, and MUA support for STARTTLS is less common than AUTH support.

Chapter 7, "Configuring qmail: Advanced Options," covers the STARTTLS patch.

---