If you have an Exchange server connected to the Internet, chances are good that some spammer has already tried to relay his junk mail through you. There are a lot of reasons why you would want to stop them from doing that, not the least of which is the potential headache of getting flamed by the recipients of "your" spam!
What Is Relaying?
Relaying is the rather cowardly practice of sending e-mail through your server to outside parties as if the spammer were actually a client of your server. For the spammer it has the effect of helping him cover his tracks and prevent the recipients from discovering his actual location. For you it causes wasted resources in bandwidth, disk space, and processor time—not to mention the added bonus of possibly getting the backlash as recipients and their ISPs inadvertently pick you as the originator of the spam.
The way they do it is pretty simple. They either connect to your mailserver directly via Telnet or specify your mailserver as their SMTP server in their mail software. Then they just try to blast mail through your server to their intended recipients. Some of them will even go so far as to fabricate a false "From:" address using your domain.
Whatever tactic they choose, the result is the same: mail gets sent, apparently from your server, to a large group of recipients out on the Internet.
Be a Rebel
The conventional wisdom when it comes to relaying has been to set the routing on your Internet Mail Service connector to "Do not Reroute." However, there are two potential problems with that:
- Your server accepts the message, text and all, before deciding not to reroute the message. That wastes time, disk space, memory, and CPU cycles on your server.
- It's possible for a malicious spammer to use your system to flood an innocent third-party with Non-Delivery Receipts (NDR) by substituting that third-party's legitimate address as the From address. Your system would decide it was a non-routable message not destined for a valid internal address and bounce the NDR back to the innocent victim the spammer had listed in the From address. If the spammer does it once, it's annoying. If they do it 100,000 times...
What's the solution? First of all, make sure you have Exchange Server 5.5 Service Pack 3 or higher.
Next, set the Internet Mail Service to route inbound mail. Go ahead and add the domains that you want to accept mail for to the list and specify that they should accept mail as "Inbound." This shouldn't be too big a task since it's a safe bet that most of you only have one or a couple of domains for which to accept mail.
Once you've done that, click the "Routing Restrictions" button and find the second choice down—where it lets you specify the IP addresses of the machines that are allowed to route mail. Before you panic and start trying to dig out the list of IP addresses your firm uses, let me say that you won't be specifying any hosts here.
As it turns out, if you leave the list of hosts blank, the IMS will check the "To:" address on any inbound message to see whether it's bound for a local domain. If it is, it accepts the message. If it isn't, it rejects the message right there and informs the sender with a "550 Relaying Denied" error—but, and this is key, not the "From:" address, who is potentially the innocent victim.
What are the advantages? The IMS will check for a valid RCPT TO (recipient) before accepting the data stream of the message. Upon detecting that the recipient is not a valid, local recipient, it will stop processing the message and return an immediate "550 Relaying Denied" error. This saves your system from having to receive, process, and store—however temporarily—the spam, keeps your system from relating the message, and prevents a malicious spammer from using your server to launch a mailbomb attack against an innocent third party.
Get More Information
Here are a few Web sites that will give you more information about this topic.
- The article, "Is Your Exchange Server Relay-Secure?" by Joseph Neubauer from Windows NT Magazine's Exchange Administrator (December, 1999), gives more details on implementing this change.
- RFC 2505, "Anti-Spam Recommendations for SMTP MTAs" (released in February, 2000), recommends a number of implementations that SMTP mail transfer agents can follow to make them more capable of reducing the impact of spam.
- Section 5 of Connected: An Internet Encyclopedia, Third Edition (Brent Baccala, Editor), called "Electronic Mail—SMTP and RFC-822", gives a detailed discussion of SMTP and the relevant RFCs.
