>< Dynamic Relay Authorization Control  ><

[ English / Japanese ]

DRAC is a daemon that dynamically updates a relay authorization map for sendmail. It provides a way to allow legitimate users to relay mail through an SMTP server, while still preventing others from using it as a spam relay. User's IP addresses are added to the map immediately after they have authenticated to the POP or IMAP server. By default, map entries expire after 30 minutes, but can be renewed by additional authentication. Periodically checking mail on a POP server is sufficient to do this. The POP and SMTP servers can be on different hosts.

For more information about DRAC, see the following topics.

SMTP Encourages Spam

One of the reasons for the popularity of e-mail spam as a means of advertizing is that the mail can be sent completely anonymously. This is possible because the standard Internet e-mail transfer protocol, SMTP, has no provisions for user authentication. SMTP originated in a network environment where e-mail users had to login to a multi-user host, supplying a user name and a password in the process, before they could send e-mail. Their e-mail address was unchangeable, and their mail program ensured that the mail they sent had that address in the headers. SMTP was used only to transfer e-mail between servers until it arrived at the destination.

This all changed when Internet mail client programs were developed that allowed people with single-user hosts to send mail. These client programs used POP (IMAP more recently) to receive mail, but used SMTP to send mail. POP and IMAP require authentication to the server, with a user name and password, but SMTP has no such thing. Users can put any e-mail address in the headers, and the SMTP server will accept it and pass it along. The SMTP server cannot distinguish between a connection from an SMTP client program and a connection from another mail server. Spammers are free to send e-mail with forged or bogus headers, and there is little that the owner of an SMTP server can do to prevent it.

I don't know if it's possible to return to the previous happy e-mail environment, but enabling mail servers to distinguish between client connections and server connections is one requirement. This would mean that one protocol for sending e-mail would be used between clients and a server, and a different protocol would be used between servers. The client-server protocol would have to incorporate user authentication and unchangeable e-mail addresses. The server-server protocol would also have to incorporate some form of authentication so that clients could not impersonate servers. Sendmail 8.10, which is now in public beta release, incorporates both authenticated SMTP and a separate message submission port. Once client support for these features is widespread, we will be well on the way to a solution to the spam relaying problem. In the meantime, a variety of imperfect methods have to be used to prevent unauthorized spam relaying.

The Roaming User E-Mail Problem

Recent versions of sendmail are configured by default to allow only local users to send mail to all destinations, non-local as well as local. This is done to prevent spammers from using your mail system to relay mail. However, if some of your users connect from other ISPs, they will find that your SMTP server refuses to relay for them as well. They can read mail from your POP or IMAP server, but they can't send mail to non-local addresses with your SMTP server.

The reason is that the only reliable information that sendmail sees is the client's hostname or IP address, and it cannot distinguish your user from a spammer with this information. If the roaming users have fixed IP addresses or predictable hostnames, you can configure sendmail to allow them to relay. If this is not the case, you would have to defeat sendmail's anti-relay provisions, or tell the users that they have to send through their ISPs SMTP server.

Allowing Relaying for Roaming Users

One method to allow relaying for roaming users is often called POP-before-SMTP. Since the POP server knows the IP address of each POP client, these IP addresses can be collected and used to build a relay authorization map for sendmail. In some cases, the information is already available in the POP server's log files. Some POP servers need to be modified to produce the necessary log entries. A separate process, such as a perl script, periodically collects new information from the log and rebuilds the sendmail map, generally by executing 'makemap'. It's also responsible for removing old map entries after some expiry period, often 30 minutes.

This means that once a user has successfully authenticated to the POP server with an e-mail client, that IP address is permitted to relay mail through the SMTP server for the next 30 minutes. In most cases, this will be completely transparent, since people generally check for new mail before sending mail. Automatic checking every five minutes will enable relaying indefinitely. A few people may be in the habit of sending mail before reading mail - they will find their mail is rejected until they authenticate to the POP server. Note that relaying is authorized by the client's IP address, so that in some cases where multiple users share the same IP address, more users than expected will be permitted to relay. It works best for single-user client machines with distinctive IP addresses. Fortunately, this is the most common situation now.

How DRAC Works

DRAC is a robust implementation of POP-before-SMTP. It uses a single daemon process, written in C, to add and eventually delete entries from a relay authorization map for sendmail. POP or IMAP servers use RPC calls to request the daemon to add entries after they have authenticated the user. Source modifications are required to add the RPC calls. The DRAC daemon also expires entries after a suitable time has elapsed. Since RPC works across the network, the POP server and the SMTP server can reside on different hosts. In this case, a configuration file specifies which hosts can send requests to the DRAC daemon.

Obtaining the Source

The current release of DRAC is version 1.12. Source is available as a compressed tar file.


DRAC requires the following software and operating systems:

Host Configuration

DRAC is a client-server system using RPC for network communication between the two. The POP or IMAP server is the client, and the DRAC daemon is the server. The DRAC daemon must run on the same host as the SMTP server, so that the sendmail map can be on a local filesystem. They can reside on the same host or separate hosts.

It's also possible to have POP/IMAP servers on several hosts that send RPC requests to a single DRAC daemon. Finally, a POP/IMAP server could be configured to send RPC requests to a list of hosts to allow relaying by several SMTP servers. DRAC by itself will not scale to suit more complicated mail server configurations, with multiple POP/IMAP servers and multiple SMTP servers, but it could become part of the solution.

Help Wanted

If you have ported DRAC to a different operating system, used it with a different MTA, or added DRAC support to a different POP or IMAP server, please send the details to Gary Mills at the University of Manitoba.

Reporting Bugs

Please send bug reports to Gary Mills at the University of Manitoba.

For information on other source distributions available from the University of Manitoba, see the source home page.

Don't go here.