Email Me Daynotes Gang |
Open Relays, Spam, and YouA discussion of Spam, methods of prevention, and the ethics and aesthetics of the prevailing systems for Spam prevention. |
|
|
|
A Day on the Known Sea |
|
|
This isn't the column I intended to do this week, which is why it's late. I decided at the last minute to go ahead with it, though, in light of Bob Thompson's announcement regarding the reception of Spam, a long thread on the Kernel Traffic mailing list for Linux Kernel development, and a few other interesting developments that happened this weekend and this morning.
We all know about Spam. Those annoying emails, offering everything from pyramid scams to get-rich-quick schemes to advertisements for legitimate business, that seem to keep popping up no matter what you do to prevent it. If you're online and popular, you get even more; I work hard to limit the amount of spam I have to deal with, but I still literally get a couple of dozen or more messages every day that DON'T get caught in filters. Others get even more, to the point that some complain they don't have time to deal with their real email for all the spam. Something, they say, must be done.
Several things are being done. One is on the legal front; in California, for example, it's illegal to send "Unsolicited Commercial Email" except under certain conditions. A couple of spammers have been successfully sued for using other people's servers for the purpose. On the server level, there are several different projects that are working on solutions for limiting Spam. Some of them are excellent, valid programs that deserve support; others are misguided, but well-intentioned attempts to make the Spam situation better; and a few are just flat wrong. Unfortunately, the most popular programs are among the worst.
First, let's look at how mail servers work, and the important distinction between "Open Relays" and "Closed Relays".
Mail Relaying
When you write an email on your computer, it doesn't (usually) go directly to the person you're sending the email to. When you hit "Send", your computer contacts your ISP's email server, and gives it a copy of the message. (This is called SMTP, Simple Mail Transfer Protocol.) Your computer then forgets about the message and is ready for you to do something else. Meanwhile, the server transmits your message for you. The other mail server - the destination - doesn't care who you are, where you are, or what server the message is coming from - it just reads the first part of the message (the "headers" - think of them as an envelope) to see who the messages is for, and delivers it. Your mail reader collects the message, and uses those headers to determine who the message is from - and it still doesn't care what server you used to send the message.
In the old days (lo these many years ago... as many as five or ten, even) the internet wasn't as stable as it is now; whole sections of the net might be cut off from other segments. To get around this, email servers often relayed for each other; Server A might have a message for Server B, but be unable to see the network Server B is on. So instead, Server A sends the message to Server C, who's between the two servers, and Server C finishes delivery for Server A. (Note: that's an oversimplification. But you get the idea.) Today, that's not so critical; the net is, for the most part, stable enough that mail can simply be sent directly from server to server. If Server A can't see Server B, it just waits and tries again later.
Also in the old days, almost all mail servers were "Open Relays". This meant simply that there were no restrictions on who could send email through their servers. It was a great convenience; if your ISP's mail server was down, you could simply use the closest convenient server to send your messages. Or maybe your usual server was slow sending mail - find a faster one until the situation improves. Most Linux users even have mail servers built in to their workstations; they can skip the whole "upload the message to a server" step and just send the message directly.
A "Closed Relay", on the other hand, is a server that DOES have restrictions. The general rule is to prevent messages from being sent by people who are not users of the system; that is, my ISP blocks all access to their email server from outside their network, reserving the resources for paid users.
The Evil Open Relay
Some people, including the people at the most common spam-fighting group, believe that Open Relay servers are inherently bad. They make it easy for spammers to send out their junk messages, and since there's no real way to hold the user responsable for their actions, the MAPS people think that Open Relays are a bad thing. So much so, in fact, that the RBL list that they run (Real-Time Blackhole List) blocks Open Relays that they find, even if the servers in question have never been reporting for sending Spam.
Why is that so bad? They've explained why the Open Relay is a bad idea, right?
The problem is that they're using the wrong approach. Computers in general and in particular networks were created in order to facilitate human communications. They make it possible to communicate, nearly instantly, with people on the other side of the planet - and to do it quickly, easily, and inexpensively. I regularly talk to friends in Australia, Asia, Africa, Europe, across the US and Canada, and in South America. I even once got an email that had been sent from Antarctica. All without leaving my home or office. Now, the MAPS people and others like them want to close that down in part. If they add a server to the RBL list, they don't care that my best friend or your mother or your business are legitimate users of that server; all they care about is that at least one message sent from that server was spam. Worse, they want to close down servers simply for being Open Relays - even if those servers have never sent a single piece of spam. They're willing to block thousands or millions of legitimate email - all because they don't like how a certain email server has been run.
A fellow daynoter pointed out recently that it was reasonable to block open relay servers for the same reason we force people to put fences around swimming pools; swimming pools pose a danger of drowning, while open mail servers pose a threat of spam. That's really not true, though. It's not the swimming pool's unfenced nature that makes it dangerous to non-swimmers; there are plenty of pools, without fences, that are perfectly safe just as there are fenced pools that are dangerous. If a pool has twenty-four hour surveilance in the form of lifeguards, a fence is not going to make it any safer - if a nonswimmer falls in the pool, someone's there to rescue them. Meanwhile, people who are comfortable or expert swimmers - "legitimate users" are not inconvenienced by the fence. On the other hand, a pool with a fence around it is not inherently safe - any parent will tell you that a three year old can find a way to anything, if they want it bad enough. Fences have holes. They have gates, loose boards, ladders left lying next to them, whatever - and meanwhile, the pool is unwatched because it's "safe".
The same is true of mail servers.
If a mail server is an Open Relay, the argument goes, a spammer could use it to send their unwanted junk, and there's no way to hold them accountable for it. Therefore, Open Relays should be shut down, and their administrators punished until they've learned their lesson. The problem is the same as the problem with the swimming pool fence argument - it's not the Openness of the relay that's a problem. The problem is that it's possible to send spam through it. If there's the equivalent of a lifeguard on duty, then where's the danger? If there's some method of preventing Spam from being sent, without restricting the activities of legitimate users - isn't that better than simply blocking the whole server? Likewise, a closed server can be abused just as much as an Open Relay; a spammer can sign up for an account from an ISP and send out his junk mail the same day. The ISP may terminate their account, but there are many, many ISPs out there. Meanwhile, those ISPs using the RBL as their spam prevention aren't doing anything to stop the spread of the Spam - but they're victimized by it when a user does it to them.
OK, so how else can servers be protected? There must be some way to prevent Spam.
The truth is that Spam will most likely always be with us. It's impossible to completely eliminate it, because the spammers are always on the offensive. This is true regardless of whether we use the RBL method, or other, user-friendly options. If you truly want to avoid spam in all its forms, forever, then walk around behind your computer, find the cord running from it to the wall (either to a network or phone jack) and unplug it. For the less extreme among us, who would simply like to make it a little less annoying, there're better options.
One such option is Brightmail and other systems like it. Brightmail works on the idea that the spam messages should be blocked, not the mail server sending them - and the individual server operator or user should be able to determine what's unwanted spam and what isn't. The idea is that Brightmail looks at the headers - the envelope, remember? - and looks for signs that the message is spam. If it matches enough of the conditions, the message goes into a "grey mail" box, where the admin or user can either delete it or check through it to make sure it's all spam, depending on their own personal taste.
This system means that some spam will leak through. It's also possible - although extremely unlikely - that some legitimate messages may be blocked. Still, the incidence of wrongly-blocked mail is much, much lower than that of the RBL, and I'd be willing to bet the success rate is much higher, too.
Another option (mainly for server administrators) is to implement some restrictions on your mail server without making it a true closed relay. For example, suppose you put a rule in your mail server that messages are sent according to the number of copies of it to be sent; something like (number of copies) times 60 equals (number of seconds between each transmission), or better yet, (number of copies) squared equals (number of seconds between each transmission). For legitimate users, the delay is negligable; for a dozen users, it either takes 15 minutes or half an hour to send the entire message. Most mail servers for ISPs won't let you send messages to more than 25 people; for that message, it would take either 25 minutes or 4.5 hours. Spammers, on the other hand, usually send the same message to hundreds of thousands of email addresses. Using the second method, if the spammer tried to send their message to 100,000 thousand recipients, it would take 317 years just to send the SECOND copy. To send the whole thing... well. Think anyone will care aboutyour message in 31.7 million years? Of course, administrators would be able to easily kill such rediculous queues. Even if they don't notice, someone will complain about an early message - and the whole queue could be killed before more than a few messages have gone out.
The point is that the MAPS people and most other spam-fighers are fighting the wrong fight. They're using the "kill 'em all and let God sort it out" approach, which is not a valid sort of reasoning. They're not helping to solve the problem - they're creating a new one.