The Internet has been around since the 1970s with people using it mainly for electronic mail (e-mail). This is still true even today as we see increasing numbers of multimedia-based applications on the Internet. People still use e-mail more than web browsers and file transfer programs. The reason is simple—it is a low-cost yet effective method for communicating with others all over the world. More and more people are getting onto the Internet, and the first thing they do is get an e-mail address.

Realizing this, certain individuals and even organizations have taken the opportunity to send unsolicited e-mail to Internet users. Most of this mail is commercial advertising. They send thousands of copies of the same message to a list of e-mail addresses obtained from either Usenet postings or companies' home pages. Such action is called spamming.

The consequence of spam is that the receiver ends up paying for the cost of the e-mail, since the ISP (Internet Service Provider) usually charges on the basis of connect time and downloading mail takes time. At companies where each employee has an e-mail address and the company has a fixed line for e-mail, that line can become quite expensive if it is targeted by spammers.

To hide their identity, spammers usually send from a forged e-mail address and use mail servers that have not been configured to prevent such activities. Relaying, as it is usually called, will cause the targeted e-mail server to send mail on behalf of the spammer to hundreds or even thousands of users. Spamming can seriously affect the performance of the mail server and cause massive bandwidth loss for the company affected. Not only will the mail server's performance be affected, but recipients of the spam will be given the impression that the company is in business with the spammer.

For more information on this, visit the number one anti-spam site on the Internet at http://spam.abuse.net/.

My company was recently the target of a spammer who used our mail server as a relay. The spammer was using an account from a well-known service provider, and my guess is that it was probably a trial account. I had not installed any preventions against such attacks and was thus targeted. When I discovered the attack, I dropped all my current work and began searching for a solution. I started by looking at the Sendmail home page (http://www.sendmail.org/). It had links that led to more tools and tips for spam prevention. I chose to implement the solution based on the smtpd package from Obtuse Systems Corporation for the following reasons:

As of this writing, the smtpd package is at version 2.0 and can be obtained from ftp://ftp.obtuse.com/pub/smtpd/smtpd-2.0.tar.gz.

smtpd works with other MTAs (Mail Transport Agent), but I have been using only Sendmail. The latest Sendmail can be retrieved from ftp://ftp.sendmail.org/ucb/src/sendmail/sendmail.8.9.1.tar.gz.

Note that you must have a working MTA before installing smtpd. It acts only as a mail proxy, storing and forwarding mail to other MTAs for the actual delivery.

Briefly, here's how smtpd works: the smtpd daemon runs and accepts mail instead of your regular mail server. It accepts mail from the Internet as well as your own domain. smtpd can be configured to reject mail based on several criteria:

Based on the configuration file, the mail is either rejected or accepted and spooled. The second program, smtpfwdd, will do the actual forwarding of the spooled mail to the MTA (Sendmail in this case).

Once you've obtained the package, unarchive the files to a directory. Assuming the files are to be put in the directory /usr/src/smtpd-2.0, do the following:

cd /usr/src
tar xvzf ~/smtpd-2.0.tar.gz
cd smtpd-2.0

Now, by typing ls, you'll see many files and subdirectories. Be sure to read README and INSTALL as these files contain valuable information on the installation of the mail proxy.

To compile the package, do the following:

The mail proxy reads its configuration from a file (smtpd_check_rules) in the /etc directory, in our example, /home/smtpd/etc/smtpd_check_rules. Each line in the file beginning with a # is a comment. Blank lines are allowed. Rules have the following format (one line):

[allow|deny|noto]:SourceList:FromList:ToList[:XXX message]

where XXX is the error message number. The first rule that matches will be taken and the check ended, so placement of rules should be done carefully.

The first field states the action to either allow an SMTP connection, deny the SMTP connection and close the session or noto which will return an error for the matching rule but will still continue for the session.

The second field is a list of IP addresses and/or host names to match the source SMTP connection. IP addresses may be specified with a netmask to include a whole network. The format of this is XX.XX.XX.XX/bits where bits is the netmask bits for the network. For instance, a network 192.168.0.0 with netmask 255.255.255.0 would be written as 192.168.0.0/24. A few special reserved identifiers that can be used are:

The third and fourth fields are used to match e-mail addresses and have the format user@host. The special word ALL can also be used in these fields.

The fifth field is optional and is used to return error messages from deny and noto to the SMTP client. The following special variables can be used to return information in the error messages:

All three fields (SourceList, FromList and ToList) must be matched in order for action to be taken.

Listing 1 is an example of a set of rules that assumes the internal network is 10.0.0.0 and a mail hub is at 10.0.0.9. Note that noto_delay will pause for a certain amount of seconds before action is taken. This option was introduced to delay relayers and spammers and the parameters that control this timeout are set in the Makefile:

NOTO_DELAY = 60
DENY_DELAY = 60

A few other configurations can be done that I have not shown here, namely the NS= pattern-check and the use of the IDENT protocol for identifying users. Users who need a more detailed setup of this file should read the file smtpd_address_check.txt in the source directory. Examples for filtering spams and relays can be downloaded from Obtuse's FTP site.

After creating the configuration file, the running mail daemon must be stopped and replaced with smtpd/smtpfwdd. For Sendmail, this can be done by typing:

> ps ax | grep sendmail
24569 ? S 0:00 sendmail: accepting connections on port 25
> kill 24569

This will effectively shutdown the mail daemon. Now, check for queued mail that the daemon has not yet sent out by issuing the command:

/usr/lib/sendmail -bp

/usr/lib/sendmail -q

Start the smtpd daemon by issuing the command:

/usr/local/sbin/smtpd -c /home/smtpd -d /spool\
-u daemon -g daemon -D
-L

The smtpd daemon will start accepting mail and spool it to the /home/smtpd/spool directory. The parameters on the command line are defined as follows:

/usr/local/sbin/smtpfwdd -d /home/smtpd/spool -u\
daemon -g daemon

A good idea is to run the MTA in such a way that it periodically processes its mail queue and sends out any mail present. Note that we actually have two spool directories here: one used by smtpd and the other by sendmail (usually in /var/spool/mqueue). To run sendmail in non-daemon mode in order to process the queue every 15 minutes, type:

/usr/lib/sendmail -q15m

Once everything is running fine, edit your startup files to run smtpd/smtpfwdd by default instead of sendmail.

The Internet is no longer the “friendly global village” we once thought it was. Living among the netizens are unscrupulous individuals and even companies that take advantage of the openness of the Internet for their own benefit while making others bear the cost. We must take preventive measures against these attacks if we want to avoid becoming victims. Proper policy on the e-mail server will help to ensure this. With smtpd in place, you will have more control of your e-mail server.