9.15 Combating the menace of spam

---

The first reported instance of spam was a message sent to ARPANET subscribers on May 3, 1978. The author was Gary Thuerk, a marketing manager with Digital Equipment Corporation, who wanted to tell people all about the new computers in the DECsystem-20 family. The note offered people the chance to come along to demos in Los Angeles and San Mateo and is possibly the first example of a marketer using email to project its message across a wide geographical distance (Digital was located on the East Coast of the United States, the target customers were on the West Coast). The message generated fury and dismay on the part of its recipients, including notes from the military officers who then ran the ARPANET.

Spammers generate huge quantities of unwanted messages that clutter up mailboxes; they send messages to lists of users whose addresses they just guess, to addresses harvested from messages posted to public forums, or lists that they purchase from intermediaries.^[10] The messages usually offer something that you cannot resist, such as the chance to get rich with no work whatsoever. Other popular topics include enlargement of various body parts, the chance to enter into intimate relations with highly detailed pictures of the human body, chain letters, urban legends, and outright hoaxes. According to some surveys, users can receive up to 1,470 pieces of spam annually (see www.imm.com for further data). While it is very annoying to have to deal with this rubbish when it arrives in your Inbox, consider just how many copies of these messages spammers have sent. Even worse, the amount of spam rises all the time, so we can only expect more of it to circulate. HP is a very large and well-known company, so it is not surprising that HP is a choice target for unwanted email. In 2002, the bastion servers guarding HP's email system dropped 30 percent of all the messages addressed to @hp.com recipients, because they came from a known spammer or contained suspicious content (such as a known virus payload), and this ratio of "blocked" to "good" email traffic rises all the time. Just one year later, in mid-2003, the percentage of dropped email had risen to 70 percent, or approximately 21 million messages per month.

If you doubt that spam is a growing menace, open up a new email account on a free service such as hotmail and wait to see how many unwanted messages turn up in your mailbox after a couple of days. In this environment, administrators have a duty to protect their servers from taking part in this activity by making sure that spammers cannot take over servers and use them as relays.

Spammers often like to use other people's systems as an intermediate relay to disguise the originator of the messages and to speed up their delivery through additional processing power (provided by your server). You may not realize that your system has been "borrowed" by spammers unless you receive complaints about email that you know has not come from one of your users, or you see sudden spikes in system load caused by an external program that may send messages to millions of recipients. Apart from the annoyance caused by spammers, if your system is used to send messages to unwanted recipients, your organization runs the risk that it will be entered on a list (sometimes called a real-time blackhole list, or RBL) of known spammers, such as that maintained by MAPS at www.mailabuse.org or the Distributed Server Boycott List at www.dsbl.org. In comparison to a blacklist, a whitelist contains the names of trusted domains that you are always happy to accept email from.

If a monitoring service adds your domain to a list of known spammers, you will have to do a lot of work to get the domain removed from the list, and other servers may begin to block all messages-including legitimate email-that originate from your domain because of your reputation as an "open relay." Antispam software uses lists of known spammers to monitor incoming email and evaluates arriving email to determine whether the message comes from a known spammer or meets some criteria that means it might be unwanted. For example, the software might do the following:

• Use simple keyword filters to examine the message subject. If the message subject contains "Get rich quick," it probably means that the message has no great business value.

• Use scoring systems or contextual analyzers that look for patterns in subjects and text that you typically find in spam. For example, the exclamation point seems to be very attractive to spammers, who feel compelled to emphasize their messages with lots of exclamations. If the scoring system finds a message that contains 20 exclamations, it could be spam. On the other hand, it could be from an enthusiastic member of your marketing department.

• Look for "fingerprints" of known spam. Antispam vendors track the characteristics of spam by analyzing message content to create a fingerprint that a filter can use to recognize similar messages.

Because these approaches vary in usefulness from environment to environment, it is a good idea to install the software and test it for a couple of weeks before you commit to a purchase. During your test, check how effective the software is at stopping spam and how it reports and disposes of spam. Does it merely block spam and provide the administrator with a list of all blocked messages and their destinations? Does it pass the message through after marking it in some way, such as changing the subject field to include "spam"? On the other hand, does it place all of the blocked messages in a quarantine filter to await your attention and perhaps allow you to redirect the messages to users after you have had a chance to examine their content and decide whether they actually fall into the category of spam?

In Exchange 2003, you can take advantage of lists of known spammers and open relays and use them as a filter to prevent spam from arriving on your server. You can also take advantage of the new junk email detection functionality that Microsoft includes in Outlook 2003 to allow users to set up their own black- and whitelists to take care of any spam that creeps through the corporate filters. (See section 4.5 for details.) Another interesting trend is for antivirus software vendors to incorporate spam filters in their products. This is a very logical progression. After all, if you check incoming email for viruses, you might as well check them for spam. Ever since Exchange 2000, antispam products can implement a transport sink with code to examine messages as they arrive at the SMTP service and before Exchange accepts them for categorization and further processing. Sybari's Spam Manager for Antigen, which integrates into its Antigen anti- virus product, is a good example of this technology in action. Relatively few software developers took up the challenge of using this technique to combat spam, largely because viruses were the major threat to servers. Viruses are still a threat, but the dramatic increase in spam prompted Microsoft to introduce a new "hook" for antispam products. This is the SCL, or Spam Confidence Level, a new Store property that antispam products can update using whatever techniques or algorithms they care to engineer into their transport sink. The SCL Processor, a new component within the Store, can examine SCL values on messages as they arrive and take action based on those values, such as to delete or refile the messages.

The higher the SCL value, the higher the probability that the message is spam. Antispam utilities use different algorithms to analyze the data in message headers and contents to determine the SCL value. You can deploy multiple antispam utilities if you like or an antispam product that utilizes a number of different scanning techniques (similar to the way that some anti- virus products use multiple virus detection engines to ensure that they catch a higher percentage of suspect messages). In all cases, the desired outcome is either to discard spam or to allow messages to pass on for further processing with an SCL score included in their properties to help client-side utilities process the messages. For example, Outlook 2003's Junk Mail processing feature allows you to choose to delete known spam messages (the default is to place these messages into the Junk Mail folder). Normally, Outlook's own junk mail processing algorithm makes the decision to refile spam messages into the Junk Mail folder after they arrive in the user's mailbox, which allows Outlook 2003 to work with Exchange 5.5 and Exchange 2000 servers. On an Exchange 2003 server equipped with suitable antispam software that sets the SCL property on incoming messages, the Store can make the decision to refile messages that an antispam utility has determined to have a high SCL value before the messages go anywhere near the client. This is better, because the client does not have to download messages, which saves bandwidth and processing.

9.15.1 Blocking relays

The most straightforward and simple defense of your system is to restrict its capability to relay. By default (Figure 9.54), only authenticated connections, such as when an Exchange server connects to another Exchange server, are able to relay messages. This may not be what you want, since you may want to support the transmission of messages from other non- Exchange servers, so review the situation and make whatever adjustments you think are necessary to secure your systems. To test whether someone can use your server as a relay, issue the following commands from a DOS prompt, selecting a non-local recipient as the addressee:

TELNET server IP address (or FQDN) 25 HELO (or EHLO) MAIL FROM: [e-mail] RCPT TO: Your [e-mail] DATA I think you have done an incredible job with Exchange. Well done!     Bill

Figure 9.54: Setting relay restrictions.

Terminate the message with a carriage return, full stop, and another carriage return. If the message is accepted, you have just proved that your system is open to relaying, but at least you now have a way to prove that Bill Gates approves of your plans to deploy Exchange. The message is not very pretty, and you can tidy it up by adding a message subject and formatting the text properly to help convince the recipient that it came from Bill Gates.^[11] A server that responds with a status code of 550^[12] after the recipient address is typed indicates that relaying is prohibited, while a 551 code means that the recipient is not local and the server will not allow you to relay to it. However, if you get a "250 OK" response to the RCPT TO command, you know that the server is open to illicit relays.

You set restrictions on message relays by changing the properties of an SMTP virtual server through ESM. (See Figure 9.55.) First click on the Access tab and then on the "Relay" button. When ESM displays the Relay Restrictions properties, by default you see that an SMTP virtual server has the "Only the list below" option set, and the computer list is empty, which effectively disables SMTP message relays. Exchange 2003 provides you with another weapon to prohibit mail relays in security principle-based submit and relay. Exchange 2000 servers control relays based on IP address, IP subnets, or DNS domain names, but Exchange 2003 servers can set an ACL to define relay restrictions for individual users or security groups. Using the same Relay Restrictions property page, you can set the relay ACL by first unchecking the "Allow all computers which successfully authenticate to relay, regardless of the list above" checkbox to enable the "Users" button. You then select the users and groups that you want to add to the ACL, which populates the ms-Exch-SubmitRelaySD attribute for the SMTP virtual server. Be careful of setting ACLs that can influence message flow. This is definitely something to test thoroughly in the laboratory before introducing into production.

Figure 9.55: Setting relay permissions.

Exchange servers do not use the settings that control external SMTP mail relays for internal traffic, even if messages flow across an SMTP connector. This is because Exchange servers authenticate together when they begin a connection with the ESMTP "X-EXPS" Kerberos authentication verb. If an SMTP server advertises this verb, Exchange will attempt to issue an X-EXPS command. Authentication will succeed if both servers are members of the "Exchange Domain Servers" security group. The Exchange installation procedure automatically adds the Exchange servers in a domain during the installation procedure. This means that you only need to allow anonymous connections on servers specifically designated to act as the inbound target for Internet or intranet SMTP connections from non- Exchange servers. "Allow anonymous" is enabled by default on all Exchange 2000/2003 servers.

There's no doubt that messaging administrators are aware of the danger that illegal relaying and spamming pose, but even with all the publicity and comment, the most recent report from the Internet Mail Consortium^[13] found that just over 17 percent of servers tested still allowed mail relays in July 1999 (the situation has not improved much since). Every one of these servers is an open target to spammers, who are all too quick to take advantage of the open door policy afforded to them. For this reason, it is a good idea to check servers on a regular basis and close off any loopholes that might have opened up.

9.15.2 Defining message filters

Microsoft does not pretend that the message filtering capability in Exchange 2000 supports the same range of functions as fully fledged content management products, such as the Clearswift Enterprise Suite (www.clearswift.com). These products, which can protect enterprises against spam, inappropriate content, and loss of confidential information, are targeted at large enterprises and the better examples integrate into the Routing Engine through techniques such as transport sinks to ensure that they can check every message that passes through the server. Both large and small companies use Exchange, and the message filtering capability is there to allow even the smallest company to gain some degree of protection.

The situation is better with Exchange 2003, since this version supports filters for connections to enforce real-time blocks to check email from known spammers as it arrives on your server, as well as sender and recipient filters to check for known senders of spam and specific types of recipients. Exchange has had great SMTP capabilities for several years, so the addition of features such as connection, sender, and recipient filters makes Exchange 2003 a more valuable component in a messaging infrastructure. These features are critical for smaller companies that cannot afford to deploy multiple layers of servers to defend their networks and want everything done by a single server. Note that Outlook 2003 and the Exchange 2003 version of OWA both include client-side junk mail filtering, so you can impose blocks on both the client and server. On an Exchange 2000 server, you can enable basic message filtering in two steps. First, you establish a global message filter policy, which includes the following features:

• Prevents acceptance of messages with a blank sender: Many spammers send messages that do not include the sender's name. Thus, you can stop a certain proportion of spam by blocking messages with a blank sender.

• Accepts messages without notifying sender: Spammers may depend on nondelivery or other notifications to know whether their messages are getting through. Your policy can accept messages and move them into a virtual blackhole, where the originator does not know that Exchange has filtered the message or delivered the message to a user mailbox.

• Archives filtered messages: You may wish to learn how successful your filtering policy is, and you can do this by capturing copies of filtered messages into the \filter directory of the SMTP virtual server's working directory (for the default virtual server, the full specification is exchsrvr\mailroot\vs1\filter). On any reasonably busy server, files will quickly accumulate in this directory, so it is not a good idea to archive filtered messages for an extended period. Use the archive to test the effectiveness of your policy, and then disable archiving.

• Establishes a filter list: Figure 9.56 shows a simple filter for a specific user, but you can also use the wildcard (*) character to set up filters such as *@hotmail.com, which blocks all hotmail messages, or *guy*@aol.com, which blocks any message from aol.com generated by someone with the word "guy" in his or her user name. Using the real-time blocks supported by Exchange 2003 is a more sophisticated and complete version of the technique.

  
  Figure 9.56: Blocking users on an Exchange 2000 server.

After setting up the policy and waiting for the System Attendant to replicate its details to the IIS metabase, you must then enable filtering on individual servers by changing the properties of the targeted SMTP virtual servers. If a message arrives at a server before you enable filtering, Exchange will process it as before. As shown in Figure 9.57, you enable filtering on an SMTP virtual server by selecting the server (from ESM), viewing its properties, and then clicking on the "Advanced button" on the General property page. Then, click the "Apply Filter" checkbox for each of the IP addresses that you wish to filter on, remembering that an SMTP virtual server can be bound to multiple IP addresses. As we will see later on, you take the same approach to apply the more extensive filter set supported by Exchange 2003.

Figure 9.57: Exchange 2000: applying a filter.

After you enable filtering on the SMTP virtual server, you can test the effectiveness of the policy by using the TELNET utility to connect to port 25 (or whatever port is bound to the SMTP virtual server) to create and send a dummy message, using one of the addresses you want to filter. If the filter is successful, Exchange captures the message in a .tmp file in the \filter directory. Figure 9.58 shows the contents of a sample message that you might capture.

Received: from ([207.209.6.159]) by exch-server.abc-server.abc.net with Microsoft SMTPSVC(6.0.3590.0);      Thu, 14 Feb 2003 15:33:14 +0000 From: [e-mail] Bcc: Return-Path: [e-mail] Message-ID: [e-mail] X-OriginalArrivalTime: 20 July 2003 15:33:16.0528 (UTC) FILETIME=[EC199700:01C1B56C] Date: 20 July 2003 15:33:16 +0000     Something that you needed to know, but really don't have to.

Figure 9.58: Sample filtered message.

If you run Exchange 2000 servers and have no plans to deploy Exchange 2003 soon, you should investigate some of the third-party antispam tools that support Exchange. Table 9.8 details some of the well-known antispam products that support Exchange. If you consider installing an antispam product for Exchange 2003, be sure that it supports the SCL hook to maximize spam suppression.

Table 9.8: Antispam Add-On Products for Exchange

Company	Product
Brightmail (www.brightmail.com)	Anti-Spam Enterprise Edition
GFI (www.gfi.com)	GFI MailEssentials for Exchange
Intellireach (www.intellireach.com)	Message Manager Suite for Exchange
NetIQ (www.netiq.com)	MailMarshal for SMTP
Sybari (www.sybari.com)	Sybari Spam Manager
Trend Micro (www.trendmicro.com)	InterScan eManager
Sunbelt Software (www.sunbelt-software.com)	iHateSpam Server Edition
McAfee (www.macfeesecurity.com)	Spamkiller for Exchange

9.15.3 Connection filters and real-time blackhole lists

Unlike the majority of SMTP add-on services or extensions, no RFC governs how real-time blackhole services work, how domains qualify for inclusion on the lists, or how you eventually decide to trust domains again and remove them from a list. Instead, you depend on third-party service providers that manage lists of the IP addresses used by known spammers that are available on the Internet as a public service. There are a number of different blackhole providers available (see http://www.declude.com/JunkMail/support/ip4r.htm), but perhaps the best known of the real-time blacklist providers is MAPS, a not-for-profit California organization (http://mailabuse.org/); many large companies use MAPS to protect their email infrastructures. The idea behind a blackhole is straightforward: If a known spammer contacts your server and attempts to pass messages, you detect the connection and either divert it to a null network device (to put messages into a "blackhole") or just drop the connection.

A service provider such as MAPS typically offers five services:

• RBL:   lists of domains known to generate and send spam

• RSS (Relay Spam Stopper):   lists of open relay SMTP servers that spammers can take over and use to send their messages

• DUL (Dial-up User List):   lists of IP addresses that have dial-up connections (normally to ISPs) used to send spam

• NML (Nonconfirmed Mailing List):   lists IP addresses that have demonstrated to be sources of mailing lists that do not verify email addresses on their lists

• RBL+:   provides one-step access to a combination of databases, combining RBL, RSS, and DUL through a single query. Large organizations most commonly use this service.

Mail servers such as sendmail have traditionally incorporated support for blackhole lists in their configuration. Many commercial products use RBL information to detect and suppress spam. Up to Exchange 2003, administrators wishing to block spam can deploy bastion servers to intercept and examine SMTP traffic coming into a company from the Internet before relaying acceptable messages to Exchange for final delivery. In HP's case, the bastion servers are Linux systems running Postfix software, equipped with RBL support. In an enterprise environment, it is probably best to keep the bastion servers in place and use them as the first line of defense against spam, and then configure Exchange 2003 to trap any spam that arrives at an SMTP virtual server as a second line of defense. If you choose, you can add yet another layer by deploying the spam suppression features that a number of antivirus products that support Exchange, such as Sybari Antigen, are adding. And, of course, there are always the junk mail features built into clients such as Outlook.

Exchange 2003 implements connection filtering in an SMTP transport sink that reads information about connection policies from the AD. You set the connection filter policies through ESM, where they become properties of the "Message Delivery" object under "Global Settings" for the Exchange organization. Once the policy is set, each time a remote SMTP server connects to a virtual SMTP server hosted by Exchange 2003, it caches its IP address and forwards it as a DNS query to the RBL service provider defined in the connection policy. The RBL service provider then actions the DNS query by checking its lists, which hold data about known spammers as special DNS service records. The RBL service provider then returns a result code to Exchange, which then checks the policy to decide whether it should accept the incoming connection. The result code is specific to a service provider and indicates why the service provider recognizes the domain (on a blacklist as a known spammer, known open relay, so it can transmit spam on a dial-up IP address). In enterprise environments, it is common for companies to purchase a service from a blacklist provider to allow them to maintain local copies of their lists (and perform lookups through a delegated DNS zone) that they update through downloads on a regular basis.

A connection policy can use multiple service providers, and Exchange checks each provider in the order listed by ESM, halting after it finds the first match. The implementation allows checking to proceed even if one of the service providers is unavailable; it also includes service providers that might specialize in detecting specific types of spammers.

9.15.4 Configuring a connection filter policy

You configure a connection filter policy by first selecting the Message Delivery object at the Global Settings node in ESM, and then selecting "Connection Filtering." The policy is broken down into a set of blacklist service configurations, or rules. You give each rule an arbitrary name to convey its purpose, and then specify the service provider (usually a DNS suffix to get the latest version of the list) that the rule will contact to check incoming traffic. The position in the list shows the priority that the rule has when Exchange checks traffic. Some lists are better at blocking specific sites than others, so you can combine as many lists as you like to attain the desired degree of protection.

A policy that is composed of two blacklists with a blacklist that provides a general block against most known spammers is backed up by a check for what you might call "bad habits." Note that you can customize the error message that Exchange returns to a submitter. The default message is SMTP code 550 with a DSN of 5.7.1 and the text "This email was rejected because your domain is reported by a DNS Blacklist Provider." In Figure 9.59, we changed the default error message to be:

The %0 mail server is on a black list owned by %2

Figure 9.59: Defining a connection filter.

When Exchange sends this response, it fills the "%0" substitution string with the IP address of the SMTP client that attempted to connect and the "%2" string with the DNS suffix of the RBL service provider. You can also include a "%1" string if you want to insert the display name of the connection filter.

9.15.5 Return status codes

You can configure how Exchange reacts to the return status code from the service provider by clicking on the "Return Status Code" button. The simplest (and default) behavior is that Exchange responds, or matches the filter, if any return code comes back. In other words, if the RBL service provider recognizes the IP address of the incoming SMTP client for any reason, Exchange will immediately end the SMTP session.

The MAPS service provider uses a well-known set of status codes:

1: On a blacklist 2: Known Open Relay 4: Dial-up IP address

If you decide that you only want to block connections from IP addresses on known blacklists, you match the filter against a mask of "0.0.0.1," as shown in Figure 9.60. The reason why the filter mask is in this format is that matches occur as the result of logical "anding" the binary bits in the last octet of the return status, which is always in the form 127.0.0.n, where n is a number between 1 and 254. For example, if we want only to block known open relays, we know that the response is going to be 127.0.0.2, so the value of the mask needs to be 0.0.0.2. If we want to catch domains on blacklists or open relays, then we use a mask of 0.0.0.3.

Figure 9.60: Configuring RBL response codes.

Exchange does not apply filters to messages addressed to "Postmaster@your-domain," because these messages notify an organization that someone has put it on a blacklist, so it is important that the messages get through. If it does not exist, the Exchange 2003 installation program assigns a secondary SMTP proxy address of "postmaster@your-domain" when you install Exchange 2003. You can allocate this address to a more appropriate recipient afterward.

As with many other system management features, it is good to be able to define special cases or exceptions where filters will not apply. You may know that a blacklist service provider has placed one of your trusted partners on a list for some reason. Negotiations are ongoing regarding removal from the list, but if you do not enter an exception, connection filtering will block any of this email. You can decide to enter an explicit exception for an email address, or you can enter an IP address mask to tell Exchange that you are willing to accept traffic from these sources. Equally, you can enter an IP address mask and decide that you never want to accept traffic from that source. Figure 9.61 shows how to enter an SMTP address as an exception. Enter IP address masks to deny or accept traffic as properties of the connection filter.

Figure 9.61: Configuring an exception.

After you have configured the connection filter, you need to select the virtual SMTP virtual servers that will use the filter. Typically, these are the SMTP virtual servers that handle Internet traffic for the organization, and you probably do not need to configure the filter on any SMTP virtual servers that handle traffic to other internal SMTP systems, such as sendmail on Linux.

Use ESM to find the Exchange 2003 server that hosts the SMTP virtual server you want to apply the filter to and expand its properties. Click on the Advanced button and then add an identity (the TCP port that the SMTP virtual server monitors) or edit the existing identity for port 25 (the default SMTP port). You can then select to apply a sender, recipient, or connection filter. In this case, you need to check the "apply connection filter" box and then click the OK button. Figure 9.62 shows the complete set of screens that you see after you select a virtual server and apply the filter.

Figure 9.62: Applying the connection filter to an SMTP VS.

9.15.6 Sender filters

If your mailbox is anything like mine, you have a number of persistent correspondents who insist on sending you details of great offers that you would prefer not to receive. You can use Outlook's junk mail filter to purge your Inbox of these messages and swap lists of known offenders with other users, but it is much more effective to be able to block this traffic as soon as it appears at the gate of your messaging infrastructure.

Connection filters eliminate a lot of spam, and Exchange 2003 supports sender filters too. A sender filter is a list of known email addresses that you never want to receive messages from. You can poll users to collect their "most hated spammer" lists or assemble the list yourself. The list illustrated in Figure 9.63 contains email addresses of people who have sent me unwanted messages, so please do not get upset if you find yourself listed.

Figure 9.63: Setting up a sender filter.

You create a sender filter list from the Message Delivery section of ESM. You can decide to filter messages that arrive with blank sender information (a typical trick of the spamming fraternity) and archive any messages that match the filter, which means that Exchange puts the message into its dump directory but does not deliver it to its intended recipient. Once you have a sender filter list, you need to apply the filter to any SMTP virtual servers that handle external traffic in exactly the same way as you apply a connection filter. If you look back to Figure 9.62, you can see that the option to apply a sender filter is the first checkbox in the set of available filters.

9.15.7 Recipient filters

Exchange 2000 is happy to receive incoming SMTP messages from any domains specified in your Internet message format policies. Given the amount of malicious content floating around the Internet, such an open framework poses some management challenges to control the content arriving on a server. Recipient filtering is the ability to block incoming email by dropping the SMTP connection if the "Mail From:" or "RCPT TO:" fields contain a string that matches addresses defined by the administrator. Exchange 2003 implements recipient filtering in a transport sink (some- times called the "Turf List" sink), which blocks messages addressed to a specific list of addresses (even if they exist as mail-enabled objects in the AD) that come from anonymous clients, as well as messages sent to addresses that Exchange is unable to locate in the AD. Messages coming in from (nonanonymous) SMTP clients, authenticated users, and Exchange servers within the same organization bypass recipient filtering.

Figure 9.64 shows how you create the list of recipient addresses to block. ESM does not validate the addresses against the AD as you enter them, but it does insist that the address includes the "@" sign. You can include the SMTP address of any mail-enabled object that you want to protect, including distribution groups. Note that you can also protect distribution groups against unauthenticated senders by setting a property of the group. The list is global in scope and is used by any SMTP virtual server to which you apply the filter.

Figure 9.64: Recipient filtering.

After you enable the recipient filter on a virtual server, each time a message is presented from an anonymous sender, the sink compares the "RCPT TO:" data in the message header to the list. If the sink discovers a match against one of the specified addresses, it returns error code 550 with a DSN of 5.7.1 ("Requested Action not taken: mailbox not available) to the SMTP client. Exchange will deliver the message to any recipient in the message header who is not in the blocked list.

If you elect to check incoming messages against the directory (set the checkbox), much of the same processing occurs and the sink validates that each of the addresses in the message header exists in the AD. If any address fails, Exchange responds with the same error code and DSN as for a blocked addressee. On first reading, you might assume that Exchange will reject any message that arrives to an addressee that is not in the directory, and you would be correct. In this case, Exchange accepts the message and performs the necessary checks to validate the address when the Routing Engine determines how best to route the message. At this stage, the Routing Engine flags the address as invalid and generates an NDR. If you set the checkbox to filter messages against the directory, Exchange checks the message as it is presented by the remote server and rejects it immediately, thus avoiding the overhead of processing the message through the Routing Engine. The net effect is, therefore, that you avoid wasteful processing by implementing the check.

^[10] . A company that provides lists of addresses to spammers is referred to as a "Spamhaus." You can get a list of well-known companies in this category from www.spamhaus.org or www.spamsites.org.

^[11] . Those interested in knowing how to create SMTP messages from programs, including the addition of subject lines and adding attachments and text, might like to browse a copy of John Rhoton's book, Programmer's Guide to Internet Mail.

^[12] . Error code 550 is defined by RFC 2505 to mean "relaying prohibited."

^[13] See http://www.imc.org/ube-relay.html. The report is dated July 5, 1999, and may have been revised by the time you read this.

---