Ignorance may be bliss in the world at large, but in the information technology field, it can lead to some serious problems. Here is a first-hand account of how my department’s ignorance of mail relaying on Microsoft Exchange 5.5 led to our server being used by spammers to spread their unsolicited junk e-mails. This eventually resulted in our mail server being put on a blackhole list, which in turn caused some of our legitimate messages to be blocked by other companies whose mail servers use those lists to avoid spammers.

It starts
A few months ago, I came across the following Event Log entry on our Exchange 5.5 Server:
To: Somepoorschnook@bigisp.com. From zoosmutz@hooya.com. Subject: Come have a wild time with us. Message: 550 Relaying not allowed.

Plenty more messages like this one followed. Some were nondeliverable because the accounts had changed or mailboxes were full. However, these messages made one thing clear: Spammers had finally detected the open mail relay running on our Exchange mail server.

We had previously come across a Microsoft Knowledge Base article on how to prevent Exchange from being used as a mail relay by spammers. It was an easy fix and worked like a charm, except it blocked an important network monitor application called Servers Alive from warning us when we had a problem with the network.

Servers Alive is a great piece of software that does a number of checks on our servers and routers and sends an e-mail message to our e-mail account and to our cell phones, giving us almost instant indications when something is down. When we implemented relay control in Exchange, Servers Alive stopped sending messages. We spent days trying to figure out why it would not work but failed to find any solution except removing the relay control from Exchange. At that stage, all we could hope was that the spammers would not find us. Unfortunately, they did.

It was a Thursday morning when the first Event Log message showed up. We tried stopping the relaying again, hoping the computer gods would allow Servers Alive to keep sending its messages this time, but we ended up with the same problem. Next, we tried stopping the spammers at the firewall. We had installed a new Raptor firewall a few months before, so we dug through the manual and found exactly what we were looking for. A number of settings in the SMTP control would block the traffic. Incidentally, there was also a setting to allow Raptor to look at an external database at www.ordb.org, which was supposed to help block spammers.

The problem intensifies
The following Monday afternoon, we checked the Exchange logs again. There was nothing there from ZooSmutz, but we had some messages like:
TeenCelebs@hooya.com Subject: We like naked celebrities – You do too

We checked the outbound Internet Mail Connector queue in Exchange and saw about 30 e-mails from TeenCelebs mixed in with our outbound e-mail. For some reason, the firewall had not blocked this one. Maybe it was new, and the database was not updated, so we set an explicit filter on the firewall and put a halt to it. Little did we know the damage was already done.

When we got in the next day and went through the logs, it looked like we had won the battle against the spammers. But we noticed some odd entries, such as spamtest@xxx.xxx.xxx.xxx (each x signifies a number in an IP address). We thought, “Wait a minute, that is our firewall IP address!” There were a few more similar entries. We started to get an uneasy feeling.

The following day, as we went through the logs, we came across an even more disturbing entry. An e-mail sent out by our vice president to a legitimate address had been blocked by a blackhole database. There was a message to check out www.ordb.org for more information. We hopped over to the site and found that ORDB stands for Open Relay Database, which keeps a database on organizations that have open relays on their e-mail servers. We punched in our IP address, and sure enough, we were on the list. We had been reported a few days earlier. The log entry we saw for spamtest@xxx.xxx.xxx.xxx was ORDB probing for our open relay.

We set about attempting to get ourselves off the list by tweaking the settings on the firewall and performing another check from ORDB. The results came back in a few minutes: We still had an open relay. We finally decided to shut the relay off at the Exchange server and knock down our cell phone alerts from Servers Alive. This time when we checked with ORDB, the result did not come back in a few minutes as before. In fact, we did not get the results until the next day. It confirmed that we were no longer relaying. Apparently, it had been trying repeatedly to verify that it could not relay messages before sending the report.

The Servers Alive issue gets solved
We decided to take one more stab at fixing the e-mail situation from Servers Alive. We set up our Intellimax LanExplorer sniffer on the ServersAlive server and had Servers Alive send a test message while we captured packets. As usual, the test failed now that we were blocking the relaying. Digging through the results, we came across the entries where Servers Alive tried to e-mail us at our office e-mail address. There appeared to be no problem. We continued digging until we came across the packets that were supposed to go to our cell phone e-mail. In the packets was a response from Exchange saying, “550 No Relaying Allowed.”

It appeared Servers Alive was automatically finding and using Exchange as a mail relay to get the message to our cell phones. We deleted the entries in the Servers Alive setup that sent a message to our cell phones and left in the entries that would send it to our regular internal e-mail addresses. That worked fine. The test messages showed up. We then set up Outlook to forward the message to our cell phones and sent another test. The test arrived in Outlook, and a few seconds later, appeared on our cell phones. We had finally solved the problem that had stumped us a few months earlier: We had stopped the relay, and Servers Alive was still functioning as it should.

Final take
This little episode was an eye-opener for us. Until a few months ago, we had no idea that many e-mail servers can simply relay messages between other mail servers without being the originator or recipient of the message. In fact, we came across the Microsoft Knowledge Base article on mail relaying by accident.

By the looks of the statistics on the ORDB Web site, we are not alone in our ignorance. It appears the number of reported open relays is growing faster than they are being closed. A visit to ORDB is well worth it. You’ll find a lot of information on open relays and how to close them, statistics and links to other blackhole databases, and various other tips. You owe it to your company and netizens at large to check to see if you are helping spammers peddle their unwanted wares.

How do you prevent your mail servers from relaying spam?

We look forward to getting your input and hearing about your experiences regarding this topic. Post a comment or a question about this article.