Junk Email

Junk email is scary--protect yourself from it with Exchange 5.5.

Douglas Toombs

July 31, 1998

8 Min Read
ITPro Today logo

Protect your Exchange server from junk email

It's out there, just waiting to find you--lurking and prowling like a thiefin the night. It tracks you down using clues you leave sprinkled across theInternet, 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 orStephen King novel--I'm talking about unsolicited commercial email. UCE is theannoying and legally questionable email that companies and individuals send tounsuspecting email recipients. You've probably received UCE such as chainletters, 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 MicrosoftExchange 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 protectyour system.

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

Internet Service Provider (ISP) administrators carefully monitor theirnetworks for abuse, so junk emailers typically don't use their ISP's Simple MailTransfer Protocol (SMTP) server to send UCE. Most junk emailers don't have theirown SMTP server, so they use a third-party server to transfer their messages.This practice is called relay hijacking, and your system performance will sufferif 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 securityrights? SMTP doesn't require user authentication or verification. A PostOffice Protocol (POP) email box requires a valid logon, but an SMTP server obeysproperly formatted commands regardless of who issues them (for details, see MarkMinasi, "Untangling Email," April). Screen 1 shows an SMTPconversation, demonstrating that no validation is required to instruct an SMTPserver to send a message. Junk emailers perform relay hijacking, takingadvantage of SMTP's security weakness to load your server with thousands ofmessages for delivery.

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

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

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_MACHINESYSTEMCurrentControlSetServices MSExchangeIMCParameters Registry key, and add the value RelayFlags as a typeREG_DWORD. This 4-bit binary flag controls the relay restrictions that Exchangeimplements. 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 relayingfrom a list of IP addresses you specify. In the MSExchangeIMCParameters key,add the value RelayDenyList as a type REG_MULTI_SZ. For the IP addresses youwant to exclude from relaying, enter the IP address and mask. For example, todeny relaying from the 10.x.x.x address range, enter 10.0.0.0;255.0.0.0. If youwant 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 canconfigure Exchange to deny relaying from every IP address, then enter specificaddresses as exceptions. Enter a decimal value of 2 in RelayFlags, and add thevalue RelayAllowList to the MSExchangeIMCParameters key as a typeREG_MULTI_SZ. Then enter the IP address ranges that you want to allowrelaying from. Screen 3 shows how you can grant relay permissions to users onthe 172.16.0.0 subnet. Only systems with IP addresses on your RelayAllowList canconnect to your Exchange server and relay messages.

Perhaps you don't know which IP addresses your system needs to allowrelaying from. For example, you might have to grant relaying permissions todial-up ISP accounts that use multiple addresses. You can configure Exchange torequire SMTP sessions to provide authorization before relaying. Enter a decimalvalue of 8 in RelayFlags to activate SMTP authorizations. Exchange then deniesattempts 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 clientwithout authorization tries to relay an email. Before setting your Exchangeserver to require authorization, you need to check your email client'sdocumentation to see whether it can present an AUTH authorization to anoutbound mail server. Outlook Express supports this option, but Eudora doesn't.

If your Exchange server is multihomed, you can enter a decimal value of 4in RelayFlags to control which interface has relay permissions. For example, ifyour Exchange server has an internal interface for your private network and anexternal interface for the Internet, you can restrict relaying to only themessages your server receives on internal interfaces. Add the valueRelayLocalIPList to the MSExchangeIMCParameters key as a type REG_MULTI_SZ, andenter the IP addresses of your internal interfaces. Exchange then grants relaypermissions to users on those interfaces and prevents users from relaying fromyour external interface.

Not Welcome Here
Exchange 5.5 lets you automatically filter inbound email from specific emailaddresses or domains. This option is useful if you repeatedly receive junk emailfrom one address or domain. Your server automatically filters messages so thatyour users don't receive junk email. (For other tips on preventing junk email,see "Client Protection Techniques.") To prevent delivery of messagesfrom certain email addresses or domains, you need to add two values to theRegistry key HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSExchangeIMCParameters. Exchange 5.5 ServicePack 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. InTurfTable, you enter a list of email addresses and domains that you wantExchange 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 systemhasn'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 itfilters, rather than saving them. You must create a directory, because theRegistry editor doesn't create one automatically. Microsoft's documentationsuggests using the directory ExchsrvrImcdataTurfdir.

When your Exchange server receives a message that meets the TurfTablecriteria, Exchange moves the message to the TurfDir directory. Screen 5, page151, 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 theemail, 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 ifthe government doesn't regulate it. It might even make email useless: Ifthousands of companies send hundreds or thousands of email advertisements a day,users' inboxes will be so stuffed with commercial email that their importantemail will get lost in the mess. Junk email is an attractive advertisingmethod because you can send an advertisement to 10 people or 10,000people for the same price (practically free). Several years ago, fax machinescreated a similar problem. Junk faxes clogged up fax machines and blockedlegitimate transmissions.

A junk email bill is currently pending before Congress: H.R. 1748, or theNetizens Protection Act. If it passes, this bill will extend the existing junkfax law (47 USC 227) to cover UCE advertisements. Consumers would have aprivate right of action against UCE, and they could sue the sender for $500 foreach piece of unsolicited advertising they receive, or $1500 if the courtbelieves the sender willfully or knowingly violated the law. If this billbecomes a law, the junk email problem will disappear. You can contact yourrepresentative to express your support for H.R. 1748. As of January, the billhad 28 bipartisan cosponsors.

Legal precedent supports compensation of systems administrators who havesuffered measurable financial loss from UCE. A Travis County, Texas, districtcourt recently ordered a junk emailer to pay $19,000 for damages stemming fromthe 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'sREADME file. For more information about junk email, go to the Coalition AgainstUnsolicited Commercial Email (CAUCE) Web site (http://www.cauce.org).

Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.

You May Also Like