Does this site look plain?

This site uses advanced css techniques

Steve Friedl's Unixwiz.net Tech Tips

Antirelay configuration in Microsoft Exchange Server 6.0

• Home
• Contact
• About
• TechTips
• Tools&Source
• Evo Payroll
• CmdLetters
• Research
• AT&T 3B2
• Advisories
• News/Pubs
• Literacy
• Calif.Voting
• Personal
• Tech Blog
• Evo Blog

Background of Antirelay Provisioning

In the "good old days", mail servers would happily forward mail to anybody who used them, and this was offered as a kind of service to the internet community at large: if your own mail server was having troubles, you could temporarily use your neighbor's mail server to route around it.

No more: those days are long gone.

Dirtball spammers have come to "hijack" mail servers owned by others to do the hard work of delivering their trash, and this has caused enormous problems for the internet. Spammers routinely scan for these "open relays" and abuse them, and eventually this gets the mail server owner either flooded with bounced mail, put on a blacklist, or both. It's much like the bad guy sneaking a box of unstamped mail into your company's mail room: you pay the postage and send out the letters.

Securing a mail server to allow only authorized users to use is important, and this paper describes the process. Modern versions of Exchange (6, and 5.5 with the latest service packs) are not hard to secure, but some common principles are applied to all antirelay provisions.

The idea is that we tell the mail server which remote users are "trusted", and in practice this is the entire internal network. Since no outside users could ever connect from these internal IP addresses, they are "trusted".

Then, when Exchange receives a connection attempting to deliver mail, it looks at the "trusted" list: those on the list can send mail anywhere, but those not on the list can only deliver to the local machine. Others are told to get lost.

Securing Microsoft Exchange Server 6.0

• First run the Exchange administrator tool, often from the desktop

  

• Navigate down the tree to get to the "Default SMTP Virtual Server" and right-click to select Properties:

  

• Click the Access tab and click the Relay... button:

  

• Select the Only the list below radio button, check the @B{Allow all computers with successfully authenticate" box, and click the Add button:

  

• Add the "Group of Computers" with the local network number and netmask.

  

• In our case, we had two sets of "internal" networks that must be allowed to relay, plus we've found that adding the "localhost" entry (127.0.0.1) is a good idea: we had to go through this process three times. This shows the result.

  

  Click OK to dismiss this and the rest of the dialog boxes.

• We believe that the SMTP service has to be restarted, so select Stop from the pop-up menu as shown, wait a moment, and when it's stopped all the way, click it again to Start the service.

  

Other Resources

Our Tech Tip is mainly meant to address the specific issue of Microsoft Exchange and not the larger issue of spam, but we can provide a few resources here in case this is the first place you've looked to get help on this.

A great resource is the Transport Security Initiative. They include links for:

• Securing MS Exchange 5.5
• A great explanation of What is Third-Party Mail Relay?
• A way to test Is my mailer vulnerable
• Links to How to fix your mailer for other platforms

Getting off the blacklists can be a lot more work, but it's not impossible. Some of the blacklists automatically delist your server after a certain time period (say, 90 days), and many others will periodically retest your server and remove your server automatically if it comes up clean. A few of the more helpful blacklist sites, often with instructions on how to reach the rest:

• ORDB - Open Relay Database
• spamcop - spamcop.net

Note: - feel free to mirror or borrow this page with or without credit. Suggestions for improving this page are welcome.