SQL Server Magazine

It's out there, just waiting to find you--lurking and prowling like a thief in the night. It tracks you down using clues you leave sprinkled across the Internet, and when it finds you it dumps a ton of garbage on your system.

I'm not talking about the villain in the latest X-Files episode or Stephen King novel--I'm talking about unsolicited commercial email. UCE is the annoying and legally questionable email that companies and individuals send to unsuspecting email recipients. You've probably received UCE such as chain letters, Ponzi schemes, or stock tips. UCE is a systems administrator's enemy, and the Internet's rapid commercialization is making the problem worse.

Perhaps you've never received junk email, but if you run a Microsoft Exchange server, your system might be a relay point for junk email. Fortunately, Exchange 5.5 offers features that will help you combat junk email and protect your system.

Modus Operandi
To better understand junk email, you need to understand junk emailers' modus operandi, or mode of operations. Junk emailers collect email addresses wherever they can find them, such as CD-ROMs of addresses, usenet postings, Web pages' Mail to tags, America Online (AOL) chat rooms, and online services member directories.

Internet Service Provider (ISP) administrators carefully monitor their networks for abuse, so junk emailers typically don't use their ISP's Simple Mail Transfer Protocol (SMTP) server to send UCE. Most junk emailers don't have their own SMTP server, so they use a third-party server to transfer their messages. This practice is called relay hijacking, and your system performance will suffer if someone uses relay hijacking to queue a few million messages on your server.

Too Trusting
How can a junk emailer access your Exchange server without having security rights? SMTP doesn't require user authentication or verification. A Post Office Protocol (POP) email box requires a valid logon, but an SMTP server obeys properly formatted commands regardless of who issues them (for details, see Mark Minasi, "Untangling Email," April). Screen 1 shows an SMTP conversation, demonstrating that no validation is required to instruct an SMTP server to send a message. Junk emailers perform relay hijacking, taking advantage of SMTP's security weakness to load your server with thousands of messages for delivery.

This mass of email clogs up your server and can shut down the server's operations for several days while you clean up your system. In addition, UCE recipients send their complaints to you, because the message header implicates your server. Junk emailers might not use your domain name in the From or Reply to headers, but your system name or IP address appears in the message's Received header, thus implicating your site.

No POP? No Problem!
The easiest way to prevent unauthorized relays through your Exchange server is to disable the SMTP routing option in the Internet Mail Service (IMS) Properties dialog box. Screen 2 shows the IMS's default routing setting in Exchange 5.0 and 5.5, which permits rerouting of incoming SMTP mail. If your Exchange server doesn't support POP3 or Internet Message Access Protocol 4 (IMAP4), set this option to Do not reroute incoming SMTP mail to prevent users from relaying mail through your system. If you support POP3 or IMAP4 clients, you can't use this option because POP3 and IMAP4 require SMTP rerouting.

Regulate Relaying
In Exchange 5.5, Microsoft incorporates a finer degree of precision for controlling message relaying than in Exchange 5.0. You can grant or deny relaying permission based on the IP address or subnet of the system sending the message, or the NIC that receives the message. You can also require SMTP authorization for relaying. You can use these settings to protect your system from abuse without disabling SMTP routing and alienating your POP3 and IMAP4 clients.

Edit the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ MSExchangeIMC\Parameters Registry key, and add the value RelayFlags as a type REG_DWORD. This 4-bit binary flag controls the relay restrictions that Exchange implements. You can add the binary values to combine the options as necessary, but the following rules are sufficient for most administrators.

If you enter a decimal value of 1 in RelayFlags, Exchange denies relaying from a list of IP addresses you specify. In the MSExchangeIMC\Parameters key, add the value RelayDenyList as a type REG_MULTI_SZ. For the IP addresses you want to exclude from relaying, enter the IP address and mask. For example, to deny relaying from the 10.x.x.x address range, enter 10.0.0.0;255.0.0.0. If you want to deny one IP address, enter the full address. You can enter 255.255.255.255 as the mask, although Exchange assumes this mask as the default.

Instead of defining each address range to deny relaying from, you can configure Exchange to deny relaying from every IP address, then enter specific addresses as exceptions. Enter a decimal value of 2 in RelayFlags, and add the value RelayAllowList to the MSExchangeIMC\Parameters key as a type REG_MULTI_SZ. Then enter the IP address ranges that you want to allow relaying from. Screen 3 shows how you can grant relay permissions to users on the 172.16.0.0 subnet. Only systems with IP addresses on your RelayAllowList can connect to your Exchange server and relay messages.

   Prev. page   [1] 2     next page