Suppose you belong to a simple lakefront beach club, where you and some neighbors jointly contribute dues to maintain the beach and docks. Now suppose that, several times a day, a rapidly moving caravan of several thousand vehicles zoomed across the beach. "Hey!" they might shout as they zoom by. "We're not using your beach; we're just passing through!"
This is what unsolicited commercial email (UCE, or spam) does to the Internet service providers (ISPs) that form our Internet beach clubs. Spam threatens the enjoyment of our pockets (and packets) of serenity by subverting resources paid for by ISP subscribers.
Such subversion comes in two forms: spam sent directly to you, where you waste time and effort downloading and deleting it; and spam that passes through your ISP's mail server on its way to some other poor sucker. (The mail server is technically called a Mail Transfer Agent, or MTA, whether it's Unix sendmail or a QuickMail SMTP gateway.)
This second problem is less discussed. A spammer can send outgoing spam through any mail server they choose - unless the mail server is secured against this, and relatively few are. This hijacking of a mail server clogs it up and invites retribution from people receiving the spam who incorrectly identify the innocent mail server that delivered it as the source of the offending mail.
It's possible for server administrators to prevent relaying and dramatically reduce spam delivery, although they can't close the door entirely.
In NetBITS-003, Adam discussed how individuals can deal with spam, including deleting it, reporting it, and supporting legislation against it. This article instead concentrates on solutions at the mail server side, which can apply equally to small offices or big ISPs. You can suggest these alternatives to your ISP if you're getting too much spam - if they implement any or all of them, expect service to improve and spam to decrease.
What Mail Is All About -- Here's a quick lesson in how email works. When you send mail, a short set of transactions takes place between your mail client (like Eudora or Netscape Communicator) and an SMTP (Simple Mail Transfer Protocol) server, which accepts the mail and later delivers it to the recipient's SMTP server.
The SMTP transaction consists of three basic commands which tell the server who sent the mail and who should receive it, and then the body of the message. The MAIL FROM command has the return address which starts the process; the RCPT TO header has the recipient's address. A DATA header follows, after which the contents of the mail message are sent, ending with a single period on a line by itself. The mail headers you're probably familiar with from reading the tops of your messages - like Received:, Reply To:, and X-Sender: - are actually inserted by the mail server into the body of the email message. They don't have anything to do with the process of sending or receiving mail.
A simple transaction looks like this (the server responses are in square brackets):
[220 spaghettini.shlomo.com ESMTP Sendmail 1.0/1.0; Mon, 13 Oct 1997 10:06:19 -0700 (PDT)] HELO nebula.frogstar.boombox.com [250 spaghettini.shlomo.com Hello nebula.frogstar.boombox.com [192.0.0.1], pleased to meet you] MAIL FROM:<email@example.com> [250 <firstname.lastname@example.org>... Sender ok] RCPT TO:<email@example.com> [250 <firstname.lastname@example.org>... Recipient ok] DATA [354 Enter mail, end with "." on a line by itself] X-Hello: Hi there! Comments: I am not an authenticated user. Hope you eat your weight in ice cream today. . [250 KAA19936 Message accepted for delivery] QUIT
The reason it's so easy to spam people is that neither the MAIL FROM nor the RCPT TO headers are confirmed by a mail server beyond verifying (and even then only rarely) that the domains themselves exist. There's no login procedure for accounts that want to send mail. And, because the mail headers are just text the server inserts, they can be forged just by typing the text in after DATA.
So sending mail from <email@example.com> is a matter of connecting to the mail server, typing MAIL FROM:<firstname.lastname@example.org>, RCPT TO:<email@example.com>, DATA, and then your text. Some mail headers can't be changed, notably the topmost Received: header, but there are ways to make it seem like mail originated from the forged address and then passed through other servers before coming to you.
That's the first part of the problem. The second is that MTAs actually "relay" mail between servers; they don't deliver it unless the address is "local." When you send mail from your local email client, the mail server first analyzes the RCPT TO address and does one of two things. If the address is local - a user who has a mailbox on that server - the MTA uses a Mail Delivery Agent (MDA) to add the mail to a mailbox. The mailbox is generally a file to which the MTA can append more information. This is true for Unix mailboxes (generally accessed via POP, or Post Office Protocol) and also proprietary systems like QuickMail, Microsoft Exchange, and cc:Mail.
If the address in RCPT TO isn't a local mailbox, the MTA acts just like a mail client and connects to another mail server that receives mail for the RCPT TO domain. It then repeats the transaction of MAIL FROM and RCPT TO. This process is relaying - your email client sends the message to your mail server, which in turn relays the message to another mail server that receives the recipient's mail. This usually involves only your mail server and the recipient's mail server. In rare cases, mail can go through several intermediate relays if the servers on either end are in large organizations or aren't connected to the Internet full-time.
Spammers subvert this process by using your mail server without permission. They specify your SMTP server as their outbound server and send mail to it; the SMTP server accepts the mail and then tries to deliver it. So, if a spammer can connect to the Internet at all, he or she can just appropriate time and space on any SMTP server.
Fortunately, users don't have to just sit back and be spammed. Let's take a look at possible solutions that you, your company, or your ISP can try.
Turn Off Relaying for Non-Local Users -- At least a million machines are running some kind of mail server or delivery agent, and sendmail V8 (also called 8.x) is the freeware Unix MTA program of choice. Some simple rules can be added to its configuration to prevent users who don't connect from previously specified addresses or domains from sending mail to users other than those to whom the mail server can deliver locally. In other words, your ISP can prevent anyone but local users from sending mail through its SMTP server.
Point your ISP to, or take a look at, the Web page below, which is a highly technical (but hopefully readable) counterpart to this article that I've aimed at those who implement these kinds of solutions. With an hour of work, any sendmail V8 configuration can be secured. There are also other resources which are referenced on this page.
Systems running MTAs other than sendmail should have options to allow connections only from specific addresses as well. Often, this restriction is turned off by default. If the mail package your company or ISP uses doesn't allow this restriction, the ISP or your company might rethink the choice of MTA or lobby the vendor for this feature. Qualcomm's latest beta of Eudora Internet Mail Server for Macintosh and Eudora WorldMail Server for Windows NT 4 both support filtering, though the Mac server is currently more flexible. The popular commercial Post.Office mailserver from Software.com for Windows NT and Unix offers relay filters starting with version 3.1.
Removing relaying can cause problems, however. A few months ago, the large ISP EarthLink Network turned off relaying for users who weren't dialed into their network in an effort to reduce spam. However, many people use EarthLink for email while at work, and they were cut off from sending email via EarthLink's mail servers. Retrieving email still worked, because it's secure: you must use your password to retrieve your email through a standard POP server. Of course, these users could use their companies' SMTP mail servers, but many companies have policies restricting use.
The benefit of eliminating relaying is enormous, though. Any site that spammers employ to relay mail can suffer twofold: first, from the added and unexpected gush of incoming spam mail that could slow down or crash a mail server; and second, from retaliation - many spam victims look at the last relay as the source of the spam and react by sending, say, 1,000 huge files or other "email bombs" in an attempt to take down the mail server. I don't condone such retaliation, in large part because it's usually misdirected at innocent by-servers.
Netcom, another large ISP, in a recent reply from their Internet abuse department, told me that they were still experimenting with what they called a "spam trap" to stop relaying. When Netcom stopped allowing non-Netcom addresses to use their mail servers, the servers bounced four million messages per week. Netcom then tackled users who bought accounts from them and spammed using other people's servers; three million messages per week were captured through this method.
Build Site-wide Spam Filters -- Spam can be rejected from specific IP numbers, domains, and email addresses. AOL pioneered this technique, although it's hard to tell whether it works. The sendmail filters noted above enable the mail server to bounce mail back to its return address automatically (with or without a custom bounce message, like, "We hate spam") instead of delivering it to local users.
Adam and I disagree over the utility of this kind of filter slightly, as he notes in his article last issue. Spammers are growing more and more clever, and usually forge return addresses uniquely each time. But spam filters can easily exclude "legitimate" spammers, like Cyber Promotions, which doesn't make any attempt at disguise. It's still difficult to identify and delete mail from <firstname.lastname@example.org> because the next time they'll masquerade as someone else, but I believe it's still worth trying.
Filtering on IP numbers works better, because faked addresses are ignored. IP numbers can't be spoofed easily (especially in mail transactions) since they involve low-level protocols. However, spammers often set up slash-and-burn ISP accounts at major providers from which they can send spam before the ISP realizes and cancels the account. If you filter on an IP number range that belonged to a major ISP because of this, you could risk filtering out a vast quantity of legitimate email.
One particular sendmail switch only allows incoming mail from real domain names. However, not all sites on the Internet have domain name resolution set up correctly, and you can wind up losing mail from people without knowing it. If you ban them from sending you email, it becomes a Dilbert cartoon: how do they send you email telling you that?
Make Money Slow -- You can take back your time and energy and put it into other things - like enjoying the sun and surf from your newly quiet patch of Internet sand. Or maybe getting some work done.
[Glenn Fleishman has been using Internet email since 1988. He receives about 40 spams a day and manages to reject 35 of them without ever seeing their subject lines.]