by Rik Farrow <rik@spirit.com>
Freeloading commercial emailers do more than fill your mailbox with unsolicited email. They also steal server time and network bandwidth, and have even crashed mailservers. And if your mail server can be used as a relay for spam, you may find your site "blackholed", cut off from sending email to many sites, in addition to getting thousands of angry email messages from the victims of the spam.
It used to be easy to track down spammers. And all it took to block spam were firewall or mail server rules that denied access from the spammers' domain. Spammers today use commercial tools designed to hide the source of the spam, as well as use third party sites as relays so the spam won't be blocked before it reaches its victims.
SMTP (Simple Mail Transport Protocol) not only makes spam possible, but it also makes it possible to track back spam to its source. All it takes is the ability to read and understand mail headers, and knowing something about how SMTP works. By denying spammers access to relay sites, we can stamp out unsolicited commercial email (UCE).
Simple Mail Transport Protocol really is simple. Like many Internet protocols, the commands are sent as text, and can be entered "by hand", using a tool like telnet or netcat. This simplicity was not an accident, as keeping things simple made debugging early Internet servers much simpler.
This same simplicity makes it easy to spoof email, something
commonly done by spammers. Figure 1 shows a complete SMTP exchange,
and uses only five different SMTP commands.
The HELO command begins the exchange,
and is customarily followed by the name of the system sending
the email. The MAIL FROM command sets the name of the sender.
Notice that any email address may be used here--there is
no authentication of the sender. Multiple RCPT TO lines, each
with a valid destination mail address may follow the MAIL FROM
line. Finally, the actual email message itself follows the
DATA command.
Spoofing email relies on lying in two places. First, by using someone elses (or a completely ficticious) email address with the MAIL FROM command. When you receive the email, the address used with the MAIL FROM command appears in the mail headers after the word From, often as the very first line of headers.
The second item the spoofer should change is the message header. The message header has its own From: line, but this one has a colon after the word 'From'. Again, the sender can put anything he or she wants here, as the mail server pretty much ignores the content of the email, that is, everything that follows the DATA command up until the single dot that terminates the mail message.
If you can't trust most of what you see in mail headers, how can you detect spam--other than the ridiculous subject lines referring to making money or increasing the size of some bodypart? The answer lies in a header line the spammer (and email spoofer) cannot change--the Received: lines.
Mail servers add received lines anytime they handle email. The Received: line includes a varying amount of information, some of which can still be spoofed. But not all, and this is the key (see Figure 2). An example Received: line begins with "from mailserver.bildoze.com/ (mail1.bildoze.com/[162.42.150.115]) by mail.acme.com". The last part of the Received: line contains the name of the mail server that received this message, and you can trust that this is accurate--if it is your mail server that received the message. The name "mailserver.bildoze.com/" is the server name used in the HELO command, and is easy to spoof. The name found in parentheses, "mail1.bildoze.com/", may be included by the receiving mail server, and is based on a reverse name lookup of the actual source IP address, which is found inside the square brackets. Not all mail servers perform the reverse DNS lookup, so you will not always see a name in front of the IP address of the sender. But because the receiving mail server knows the sender's IP address, you can trust this information as well.
When the name following "from" is different from the name within parentheses, or obtained by using nslookup (or Sam Spade) on the IP address, someone is spoofing SMTP. The hostname portion can be different, as servers can have multiple names (mailserver and mail1, as shown in the example). But the domain name (bildoze.com) must be the same, and when the name supplied by the HELO message is different from the one found by an actual DNS lookup, the email you are looking at has been forged.
You might see many Received: lines in an email header, so you must determine which is the one to check for forgery. In many cases, the last Received: line was the first one added by a mail server, and this one will show evidence of forgery. But spammers have taken to adding fake Received: lines as part of the message header to make picking out actual sender more difficult. Here is where understanding the rest of the Received: line comes in. Each Received: line contains not only a "from sender" part, but also a "by receiver" clause, and the next line up in the chain should show that the receiver has become the sender, as mail is relayed to the receipient. If this is not true, then the Received line has been forged.
Spam would be relatively easy to block if it all came from a list of well-known servers. You could configure your firewall to block access from any address in these networks, or do the same thing with your email server. And many sites, including some very large ones like AOL, have already done this. But this hasn't stopped the spammers. Instead, they have taken to using other peoples' mail servers to relay their spam.
Any mail server can be a relay. Relaying used to be quite common in the early Internet, even required by some transport protocols, like UUCP (UNIX to UNIX Copy Program). Today, relaying is something that an ISP might do for its customers, and some large organizations might want to do for some of its members when used with authentication. But having an open relay is an invitation to spammers.
Remember the RCPT TO command in the SMTP protocol? To relay mail, the spammer provides many RCPT TO lines, all with email addresses that don't belong to the same domain as the mail server. The relay mail server dutifully delivers each email, a process that involves using DNS to look up the correct mail exchanger (MX) records, then connecting to the server, using the SMTP protocol and finally delivering the mail. Relaying makes it possible for someone using a slow, dial-up link to reach millions of targets, because the relay mail server does the lion's share of the work.
Of course, using someone else's server to relay mail is a form of theft. The spammer is making unauthorized use of the mail relay, a use that has been known to crash some mail servers. Sites that unwittingly assist in the delivery of spam may then find themselves added to a blackhole list--a list of sites known to be relayers for spam. If your site gets blackholed, no one at your site can successfully send any email to sites subscribed to that blackhole list.
Blackholing has been successful in reducing the number of sites that will act as relays for spam. It has also incurred the wrath of spammers, who have hired lawyers to attack the blackhole sites (see Resources). If you had a way of making money by mailing advertisements at other people's expense, wouldn't you be upset when some group attempted to block you? Well, perhaps not, because stealing computer and network resources from other people is just something you wouldn't do.
Spammers have tools for automatically locating open relays. According to the MAPS (Mail Abuse Prevention System) site, the number of open mail relays has declined from around 50% in 1996 to less than 20% in 1999. That is still a very large number of potential relays, but things have gotten better. In the mid-nineties, some popular firewall products would actually work as mail relays.
You can test your own site's public mail servers by connecting to port 25 (the SMTP server port) and attempting to relay mail. The key is to use an email address in the RCPT TO command that does not belong to the domain of the mail server. You must do this from a system that is outside of your domain, or you can use a relay tester, such as the one found at www.abuse.net/. You should get error messages, beginning with a 5, such as 553 Requested action not taken: mailbox name not allowed.
Sendmail, the most commonly used mail server software for UNIX/Linux systems, comes with relaying disabled by default. Microsoft Exchange and Lotus Notes may have relaying enabled, and it appears that most of the relay servers used in the spam I receive come courtesy of an Exchange server (this information is also contained in the Received: line where you can detect the forgery). Version 4.0 of Exchange will not perform relaying without patches. Version 5.0 can support relaying if routing is enabled--which is required for supporting POP clients. Version 5.5 (and SP1) add a lot more control over who can use Exchange for relaying. I strongly suggest that you read the Release Notes so that you configure Exchange so that only users within your domain can use Exchange for relaying.
Take a few minutes to check and see if your site can be used as an open realy for spam. Consider joining organizations that provide realtime support for blocking spam. UCE/spam is more than a nuisance-- it is widespread, unauthorized use of servers and networks. Compared to other Denial of Service attacks, spam is the most common. Stop being a victim.
The MAPS site, www.mailabuse.org, is where you can subscribe to access their various services for blocking sites that relay or distribute UCE: http://mail-abuse.org/rbl/
Very useful page for help in interpreting mail headers: http://www.stopspam.org/email/headers/headers.html
Explanation of third-party relaying: http://mail-abuse.org/tsi/ar-what.html
A site dedicated to stopping mail abuse, with a relay tester: http://www.abuse.net/relay.html
Sam Spade for IP address lookup and more: http://samspade.org/t/ A site that forwards a different approach to stopping spam--presenting fake relays that absorb instead of forward spam: http://fightrelayspam.homestead.com/
Figure 1: The SMTP protocol was designed to be simple so it would just work--security was not a consdieration. In this example, I sent mail to my wife from god@heaven.org.
bear ) nc localhost 25
220 bear.spirit.com/ ESMTP Sendmail 8.10.1/8.10.1;
Mon, 3 Sep 2001 17:37:59 -0700 (MST)
HELO localhost
250 bear.spirit.com/ Hello rik@localhost.spirit.com
[127.0.0.1], pleased to meet you
MAIL FROM: god@heaven.org
250 2.1.0 god@heaven.org... Sender ok
RCPT TO: rose@spirit.com
250 2.1.5 rose@spirit.com... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
Received: from heaven (heaven.org[192.168.22.2])
by purgatory.spirit.com/
From: god@heaven.org
To: rose@spirit.com
Date: Tue, 28 Aug 2001 05:21:05
Have you tithed today?
.
250 2.0.0 f840cIR09676 Message accepted for delivery
QUIT
221 2.0.0 bear.spirit.com/ closing connection
Figure 2: Received: lines are added by mail servers that relay
or deliver mail. This example, taken from some UCE, shows that
the name "plain" was
used in the HELO message, but the actual source IP address was
12.99.89.82, which resolved to 82.mubb.snfc.snfccafj.dsl.att.net.
The open relay used was netf5000.sitico.com.cn/, which is running
Exchange version 5.5.
Received: from plain ([12.99.89.82]) by netf5000.sitico.com.cn/
with SMTP (Microsoft Exchange Internet Mail Service
Version 5.5.1960.3) id R9ZHFWFT; Sat, 1 Sep 2001
05:18:07 +0800