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.
Perhaps you don't know which IP addresses your system needs to allow relaying from. For example, you might have to grant relaying permissions to dial-up ISP accounts that use multiple addresses. You can configure Exchange to require SMTP sessions to provide authorization before relaying. Enter a decimal value of 8 in RelayFlags to activate SMTP authorizations. Exchange then denies attempts to relay messages from mail clients that don't provide proper SMTP AUTH authorization. Your Exchange server verifies this authorization against your Windows NT accounts database and denies relaying if it doesn't find a match. Screen 4 shows the error message that results when an Outlook Express client without authorization tries to relay an email. Before setting your Exchange server to require authorization, you need to check your email client's documentation to see whether it can present an AUTH authorization to an outbound mail server. Outlook Express supports this option, but Eudora doesn't.
If your Exchange server is multihomed, you can enter a decimal value of 4 in RelayFlags to control which interface has relay permissions. For example, if your Exchange server has an internal interface for your private network and an external interface for the Internet, you can restrict relaying to only the messages your server receives on internal interfaces. Add the value RelayLocalIPList to the MSExchangeIMC\Parameters key as a type REG_MULTI_SZ, and enter the IP addresses of your internal interfaces. Exchange then grants relay permissions to users on those interfaces and prevents users from relaying from your external interface.
Not Welcome Here
Exchange 5.5 lets you automatically filter inbound email from specific email
addresses or domains. This option is useful if you repeatedly receive junk email
from one address or domain. Your server automatically filters messages so that
your users don't receive junk email. (For other tips on preventing junk email,
see "Client Protection Techniques.") To prevent delivery of messages
from certain email addresses or domains, you need to add two values to the
Registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIMC\Parameters. Exchange 5.5 Service
Pack 1 (SP1) will provide a user interface you can use to add the values.
The first value you need to add is TurfTable, as a type REG_MULTI_SZ. In TurfTable, you enter a list of email addresses and domains that you want Exchange to filter. You can specify certain addresses (e.g., [email protected]) or entire domains (e.g., @public.com).
If you want to be able to scan filtered messages to ensure that your system hasn't deleted an important message, enter the TurfDir value, as type REG_SZ. TurfDir tells the Exchange server which directory to put filtered messages in. If you don't have this value in your Registry, Exchange deletes the messages it filters, rather than saving them. You must create a directory, because the Registry editor doesn't create one automatically. Microsoft's documentation suggests using the directory Exchsrvr\Imcdata\Turfdir.
When your Exchange server receives a message that meets the TurfTable criteria, Exchange moves the message to the TurfDir directory. Screen 5, page 151, shows a test message I sent myself from an address on my TurfTable list. Exchange wrote an event to the application event log that says it filtered the email, as Screen 6, page 151, shows. I didn't receive the message.
Call Your Congressman
Junk email is a widespread problem on the Internet, and it will get worse if
the government doesn't regulate it. It might even make email useless: If
thousands of companies send hundreds or thousands of email advertisements a day,
users' inboxes will be so stuffed with commercial email that their important
email will get lost in the mess. Junk email is an attractive advertising
method because you can send an advertisement to 10 people or 10,000
people for the same price (practically free). Several years ago, fax machines
created a similar problem. Junk faxes clogged up fax machines and blocked
legitimate transmissions.
A junk email bill is currently pending before Congress: H.R. 1748, or the Netizens Protection Act. If it passes, this bill will extend the existing junk fax law (47 USC 227) to cover UCE advertisements. Consumers would have a private right of action against UCE, and they could sue the sender for $500 for each piece of unsolicited advertising they receive, or $1500 if the court believes the sender willfully or knowingly violated the law. If this bill becomes a law, the junk email problem will disappear. You can contact your representative to express your support for H.R. 1748. As of January, the bill had 28 bipartisan cosponsors.
Legal precedent supports compensation of systems administrators who have suffered measurable financial loss from UCE. A Travis County, Texas, district court recently ordered a junk emailer to pay $19,000 for damages stemming from the emailer's forging of a domain's return address for UCE.
For Further Reading
To learn more about Exchange 5.5's UCE-related features, see Exchange's
README file. For more information about junk email, go to the Coalition Against
Unsolicited Commercial Email (CAUCE) Web site (http://www.cauce.org).
