Chapter 20: Supporting Internet Protocols and SMTP

This chapter covers the Simple Mail Transfer Protocol (SMTP), Post Office Protocol version 3 (POP3), Internet Message Access Protocol version 4 (IMAP4), and Microsoft Outlook Web Access (OWA). At first glance, these might seem the sort of dry topics that only a true geek would appreciate. In reality, however, a good understanding of the basic Internet protocols will greatly assist your efforts in troubleshooting and understanding the Microsoft Exchange Server 2003 architecture.

SMTP is the native transport protocol for Microsoft Exchange Server 2003 and is used by the Routing Group Connector, by the SMTP Connector, and for general communications between Exchange 2003 servers. The other protocols— POP3, IMAP4, and OWA—are considered different ways to access the Store process. Understanding the advantages and limitations of each protocol will benefit your planning, implementation, and troubleshooting efforts.

Simple Mail Transfer Protocol

Because it is impossible to provide an in-depth analysis of SMTP in this book, this section concentrates on the parts of SMTP that are most relevant to administering and troubleshooting Exchange Server 2003.

Simple Mail Transfer Protocol (SMTP) has its roots in the File Transfer Protocol (FTP). Before SMTP was originally defined in RFC 561, it was customary to copy messages to their destinations as simple files, using FTP. The problem with this technique was that it was sometimes difficult to discern who had sent the file and to whom the file was being sent, due to the lack of identifying information. What was needed was the ability to pass information between two hosts while identifying who the sender and recipient were.

In 1973, the beginnings of such a message structure were defined, containing some header fields and the body of the text. Further refinements came in RFCs 680, 724, and 733 before the current standard in RFC 822 was issued. Now each header line consists of a field name terminated by a colon and followed by a field body. For a message to be valid, the creation time, source, and destination fields must be filled in. Other optional fields, such as received, subject, reply-to, and return-path, can be filled in as well. As the message passes from one Message Transfer Agent (MTA) to the next, these required fields are enumerated and then added to the message header, allowing the recipient to see how the message was transferred through the mail system.

More Info

For more information about the standards for transferring messages, refer to “F.400/X.400 Standard: Data Networks and Open System Communication Message Handling Systems,” from the International Telecommunication Union at http://www.itu.org.

The SMTP design is based on a communication model that follows these basic steps:

1. The user makes an e-mail request to a sender-SMTP.

2. The sender-SMTP establishes a two-way transmission channel to a receiver-SMTP.

3. The sender-SMTP generates SMTP commands and sends them to the receiver-SMTP.

4. The receiver-SMTP sends response commands to the sender-SMTP.

For example, if User1 wants to send e-mail to User2 over SMTP, the sequence of events would be as follows (assuming that both users are running the SMTP service on their computers):

1. User1 contacts User2 and establishes a two-way transmission channel over TCP port 25, using the HELO command.

2. User1 sends a MAIL command indicating the sender of the e-mail. This is how we know who sent the e-mail.

3. User2 sends an OK reply.

4. User1 sends a RCPT command identifying the recipient of the e-mail. This is how we know who the recipient of the e-mail is.

5. User2 sends an OK reply.

6. User1 sends the e-mail.

7. User2 sends an OK reply.

8. User1 sends the QUIT command.

9. User2 sends an OK reply and then terminates the connection.

The commands from the sender and receiver are always sent one at a time, and one reply is sent for each command. SMTP does not support multiple commands sent as a batch to another SMTP host. Table 20-1 lists the more common SMTP commands and their purpose.

Table 20-1: Summary of SMTP commands

Command	Description
HELO	Identifies the sender-SMTP to the receiver-SMTP based on host names.
MAIL	Initiates e-mail transfer with indication of originator (reverse path argument). If routed through a relay agent, the first host in the list is the most recent relay agent. Non-delivery reports generated by the receiver-SMTP are sent back using this command.
RCPT	Identifies one of the recipients (forward path argument). Multiple recipients are specified by multiple use of this command. The forward path can optionally include a list of relay hosts, but it must include the final destination mailbox.
DATA	Indicates that message data is ready to be sent in 128-ASCII-character codes.
RSET	Resets e-mail transfer. Received e-mail data is discarded.
VRFY	Asks the receiver-SMTP to verify that the e-mail address identifies a user.
EXPN	Asks the receiver-SMTP to confirm the identity of a mailing list and return the membership of that list.
HELP	Requests help on a command.
NOOP	Requests the receiver-SMTP to send an OK.
TURN	Reverses roles of sender and receiver.
QUIT	Requests termination of connection. The receiver-SMTP must send an OK and then close the transmission channel.

7-Bit ASCII Character Set

SMTP commands are sent in the American Standard Code for Information Interchange (ASCII) 7-bit character set. This fact is important because the TCP architecture assumes an 8-bits-per-byte transmission channel.

E-mail started in the United States and at first was used to send text only. Because the entire English alphabet and standard English punctuation marks can fit into the 128 (2⁷) possible combinations of 7 bits, the 8th bit was used as a parity bit, giving some extra redundancy in error checking.

The first 128 characters in the ASCII character set define the 26 letters of the English alphabet in both lowercase and uppercase and the more common punctuation marks that might be used in everyday messaging. Messages that use only these characters are said to be 7-bit ASCII.

Extended ASCII Character Set

Because there are many more than 128 characters in the international alphabets, the extended ASCII character set defines 256 characters, accommodating most European alphabets. Defining this many characters means using the 8th bit for character generation instead of for parity. The problem with doing so is that SMTP doesn’t permit the use of the 8th bit. Thus, even if you could find an SMTP MTA that would pass all 8 bits, the 8th one would be lost because the protocol itself works only with 7 bits. The solution to this problem has been to fit 8 bits into 7 bits at the sending end and then extract them at the receiving end. Since bits don’t compress very well, we add some extra bytes so that the bit combination is cleanly divisible by 7.

We accomplish this task by taking 7 bytes, each with its underlying 8 bits, lining them up sequentially at the bit level, repackaging the bits so that 7 bits equals 1 byte, and then sending the bytes across the line. For instance, if you have 7 bytes, each with 8 bits, you could line up the bits and create 8 bytes of 7 bits each. At the receiving end, the bits are repackaged into 7 bytes of 8 bits each.

Uuencode is a UNIX-based utility that repackages a file with 8-bit data into another file with 7-bit data so that it can be ported across SMTP. The recipient invokes uudecode to convert the data back to an 8-bit standard.

MIME Format

In today’s world, we aren’t just sending text back and forth—we are sending files from a wide variety of PC applications and languages. This level of complexity is where Multipurpose Internet Mail Extension (MIME) comes in. MIME provides a way to send more than just text across the Internet. It is a standard that allows multiple files of various content types to be encapsulated into one message. RFCs 2045 through 2049 currently define MIME and are considered to be a single standard.

MIME works by concatenating all the attachments, placing separators between them. Each body part specifies a content type that indicates the kind of file it represents, and it also indicates how the file is encoded for transfer through the e-mail system.

Each content type consists of both a top-level media type and a corresponding subtype. It is possible to define additional types other than those specified in the RFCs to accommodate proprietary formats. Table 20-2 lists the more common top-level types and their corresponding subtypes. Each of the five discrete types corresponds to a single file. The composite types can encapsulate discrete or other composite contents.

Exchange Server 5.5 is based on the X.400 protocol, which is considered to be a closed backbone message transfer system. By closed we mean that in an X.400 backbone, you need to explicitly define all peer MTAs on the network or over the Internet. SMTP, on the other hand, is considered to be an open message transfer system because any computer running SMTP will generally accept connections from any other computer running SMTP, and these peer connections do not need to be specified in advance. Because the default transport protocol for Exchange Server 2003 is SMTP, Exchange Server 2003 has greater interoperability with foreign e-mail systems than Exchange Server 5.5.

Table 20-2: Top-level media types

Media Type	Subtypes
Discrete
Text	Plain, rich text, enriched
Image	Jpeg, gif
Audio	Basic
Video	Mpeg
Application	Octet-stream, Postscript
Composite
Multipart Message	Mixed
	RFC 822

Each SMTP server routes messages to the next SMTP server based on the e-mail exchanger (MX) records it finds in the DNS. SMTP transfers messages over a TCP port 25 connection. If you’re coming from a Microsoft Exchange 5.5 Server environment, you might be surprised to learn that the MTA is not involved in SMTP message transfers. In Exchange 2003 (and Exchange 2000), the MTA does not play a prominent role when it comes to message transfers. The MTA still exists for connections to other MTA-based systems, such as Exchange 5.5 or Lotus cc:Mail, and it is still used for e-mail that travels over an X.400 Connector, but the core protocol for moving messages around your Exchange 2003 environment is SMTP, not the MTA.

SMTP Service Extensions

In November 1995, RFC 1869 was published, containing several extensions to the SMTP command structure. These extensions, which are registered with the Internet Assigned Number Authority (IANA), allow the receiver-SMTP to inform the sender-SMTP of the service extensions it supports. The purpose of this revision in the SMTP standard was to make SMTP adaptable in the coming years. When SMTP is extended, it is referred to as ESMTP.

When working with extensions, the sender-SMTP sends an EHLO command in place of the HELO command. The receiver-SMTP can respond by indicating which extensions it supports. If it does not support any extensions, it sends an error response.

Exchange Server 2003 takes advantage of these extensions by using the ETRN command, which is the extended version of the TURN command. This command asks the computers not only to reverse roles but also to verify the remote host name so that hosts other than the one for which the messages are intended cannot retrieve the messages. Because of the host name verification, which includes the domain name, ETRN is used to trigger e-mail delivery for a specific domain rather than for a specific host.

Exchange Server 2003 and the SMTP Service

SMTP is really the heart of Exchange 2003 transport services. The SMTP service installed by Exchange 2003 supports many of the ESMTP commands. Although there is only one SMTP service, you can configure multiple virtual SMTP servers on each Exchange 2003 server. Each virtual server can be started, stopped, or paused independently of other virtual servers. However, stopping or pausing the SMTP service itself will affect all the virtual servers. (See the next section, “SMTP Virtual Servers,” for more information.)

When the SMTP service is running, new connections can be accepted from users. When it is stopped, all users’ connections are severed. When the SMTP service is paused, each virtual server continues to service currently connected users but will not accept new users.

Installing Exchange Server 2003 extends the base SMTP service to add functionality, including the following:

• Commands to support link state information (X-LINK2STATE)

• The advanced queuing engine

• The enhanced message categorization agent

• The Installable File System (IFS) store driver

  Note

  Even though the IFS is installed and running in Exchange Server 2003, the databases are not exposed via the M: drive by default as they were in Exchange 2000 Server. So, the IFS is loaded and running whether or not you see the M: drive in Exchange 2003.

Figure 20-1 shows a sample log file for the SMTP service as it records the sending of a message from the local server to a remote server. Some of the commands, such as X-LINK2STATE and XEXCH50, are unique to Exchange Server 2003 and are considered ESMTP commands. You can see how the log file allows you to use the SMTP commands to troubleshoot SMTP services.

Figure 20-1: Sample log file.

More Info

The log file is discussed further in the “Configuring and Administering a Virtual Server” section, later in this chapter.

SMTP Virtual Servers

As we mentioned earlier, in Exchange Server 2003, you can create multiple SMTP virtual servers on the same physical server to provide separate configurations for different messaging services. In most cases, additional virtual servers are not needed. However, if you are hosting multiple domains or want to have more than one default domain name, you can create multiple virtual servers to meet your needs. From the user’s perspective, each virtual server appears as a separate SMTP server.

Another reason to create multiple virtual servers is to satisfy different authentication requirements for different groups of users. You can create as many virtual servers as you need to handle the different configurations. Every virtual server on any one physical server must belong to the same routing group. Multiple virtual servers won’t increase your throughput, but they are very handy if you need to configure different options for different sets of users.

Each virtual server has its own distinct configuration, including IP address, port number, and authentication settings. By default, each Exchange 2003 server has at least one virtual server that listens on port 25 on all IP addresses. This can be changed, of course, but the default SMTP Virtual Server (VS) is coded to do this out of the box.

There are two ways to create a new SMTP VS. The first approach involves launching the Exchange System snap-in. Then, under the server object, navigate to and expand the Protocols container. Right-click the SMTP container, point to New, and then choose New SMTP Virtual Server. The New SMTP Virtual Server Wizard starts (Figure 20-2) and asks you to enter the name of the virtual server. Choose a descriptive name because this is the name the object will have within Exchange System.

Figure 20-2: First page of the New SMTP Virtual Server Wizard, in which you name the virtual server.

The next page of the wizard asks you to select an IP address for this new virtual server (Figure 20-3). Be sure to select an address that is different from the IP address of the default SMTP server. Each virtual server requires a unique IP/port number combination. Once you’ve made your selection, click Finish to create the new virtual server.

Figure 20-3: Selecting an IP address for the new virtual sever.

Tip

The IP address you specify will need to have been bound to the server before you attempt to create the virtual server. Also, be sure to add an address (A) record and an MX record in DNS for this virtual server.

The second way to create a new virtual server is through the new Internet Mail Wizard (IMW). You run the IMW by right-clicking the Organization object and then following the screen prompts. If you’re coming from an Exchange 5.5 environment, you’ll find this wizard to be similar in concept to the Internet Mail Connector Wizard. The IMW is intended for those who are less familiar with the SMTP server in Exchange 2003 and who either don’t have the time or are uninterested in learning how to configure the SMTP VS manually for inbound and outbound Internet e-mail.

In those environments with a dedicated Exchange or messaging staff, this wizard will be of little value because the staff will possess the skills to create and manage the SMTP virtual servers without additional help. If you work in an environment in which individuals have minimal Exchange skills and you want to ensure e-mail delivery for both inbound and outbound e-mail, the wizard will help you get e-mail moving.

Be aware of the following considerations when using the IMW:

• It is intended primarily for small and medium companies with less complex environments.

• It will create an SMTP Connector.

• If you have any connectors or additional SMTP virtual servers, the wizard will not run.

• You cannot use this tool to configure an Exchange 5.5 or earlier server.

To run the Internet Mail Connector Wizard, right-click the Organization object, and select Internet Mail Wizard. The second screen after the Welcome screen lists the following prerequisites for configuring the default virtual server:

• You have a registered domain name on the Internet.

• You have an Internet-assigned IP address.

• You configured DNS with an MX record that points to your Internet IP address.

If you have already implemented the prerequisites, getting e-mail in and out of your organization using the default SMTP VS will be straightforward. By default, the SMTP VS is set up to transfer messages in and out of your organization.

After you ensure the prerequisites are configured correctly, you select the server on the Server Selection page (Figure 20-4) and click Next.

Figure 20-4: The Server Selection page.

The next page in the Internet Mail Wizard runs a check on that server (Figure 20-5) for compliance with requirements. For example, the server cannot be a member of a load-balancing cluster, and the server cannot act as a router between two networks.

Figure 20-5: Wizard In Progress page that runs the compliance checks.

On the Internet E-Mail Functions page, you can select whether you want the VS to receive and/or send Internet e-mail. Make your selections, and then click Next. Note that the default SMTP VS is set up to both send and receive e-mail, but the IMW lets you set the default SMTP VS to only send or only receive e-mail. For example, if your users download their e-mail from a POP3 server, you can set up the SMTP VS to only send e-mail, not receive it. Only sending mail is becoming a rare scenario, but it prompted the creation of the IMW for the novice or busy Exchange administrator.

When you have an Exchange server that is dual-homed with one card assigned an Internet IP address and the other assigned a private IP address, the Configure Your Server page will appear next in the IMW (Figure 20-6). If you select Yes at this juncture, a second SMTP VS is created for Internet Mail using the Internet-assigned IP address. The default SMTP VS is assigned to listen for SMTP traffic on the private IP address. In our example, we’ll select Yes so that you can see the effect.

Figure 20-6: The Configure Your Server page.

The next page (Figure 20-7) is the Create Two SMTP Virtual Servers page. You need to assign an IP address to each VS. The internal VS will receive the private IP address and the other VS will be assigned the Internet IP address. We’ll discuss the effect of doing this in just a moment.

Figure 20-7: The Create Two SMTP Virtual Servers page.

More Info

Some IP address ranges have been set aside by the Internet authorities for use only on an intranet that is protected or disconnected from the Internet. Hence, these ranges of IP addresses are described as private. One such range is 192.168.0.0 with a subnet mask of 255.255.0.0. To better understand the terms “private” IP address and “Internet” IP address, read the Microsoft Windows Server 2003 TCP/IP Protocols and Services Technical Reference (Microsoft Press).

After you decide to create an additional VS, you must indicate the domains on which these virtual servers will be transferring e-mail on the SMTP Domains for Inbound Email screen. Enter the domain names using the Add button and then click Next. The default domain name for the Exchange server will appear automatically. To receive e-mail for more than one domain, enter the configuration value on this screen.

The next screen is the Outbound Bridgehead Server (BHS) screen. Here you select which server will act as the outbound BHS for the SMTP Connector that is created by the IMW. The default SMTP VS of the server you are configuring will appear here. Accept the default selection, and then click Next.

The Outbound Mail Configuration page (Figure 20-8) appears next. This page allows you to select two different settings for outbound e-mail:

Figure 20-8: The Outbound Mail Configuration.

• Resolve outbound e-mail destination domain names using DNS.

• Forward all outbound e-mail to a smart host and let that smart host resolve and send your e-mail to the destination SMTP servers.

If you make the first selection but then select the associated No option, the next screen will ask you to give the wizard a DNS server to reference that can resolve the destination domain names to their IP addresses. If the DNS server that the Exchange server you’re configuring can resolve the destination DNS domain names for outbound e-mail, select the Yes option.

The next page in the wizard is the Outbound SMTP Domain Restrictions page, which allows you to configure restrictions for particular destination domains that this SMTP VS will be allowed to transfer e-mail to. The default is to deliver e-mail to all domains as addressed by your users, which is, by far, the most common choice.

The final page is a Configuration Summary page. Here you can review your choices. It is important to note that no configuration changes have occurred during the course of running this wizard—your changes are not written to the Exchange server until you click Next. After you click Next, the configurations are written and the needed virtual servers are created. Finally, you are presented with the Completing The Internet Mail Wizard page, so click Finish to close the wizard.

In our example, we used the wizard to work with a dual-homed Exchange server that had one Internet and one private IP address. What changes were written to Exchange? First, each VS is now assigned to a single IP address, and the default VS is no longer configured to use All Assigned IP addresses. Second, an SMTP Connector was created that uses the internal VS as its BHS. Because the server we used was dual-homed, we were given the option of creating a VS for each unique IP address and port number combination that was available. In this instance, we were allowed to create a VS for the Internet IP address and one for the external IP address, even though both used port 25. Without dual network cards, we would not have been able to create the second VS using the IMW.

Configuring and Administering a Virtual Server

Once you’ve created the virtual server, you can configure its property sheet by right-clicking the virtual server and choosing Properties. On the General tab (Figure 20-9), you can enable logging on this virtual server so that you can track user connections. Four formats are available for log files:

Figure 20-9: General tab of the property sheet for a virtual server.

• W3C extended log file format The default log file format for IIS and SMTP. Information is written to an ASCII text file. Unlike other formats, you can choose what is written into the log and can limit the size of the log file itself. There are usually multiple entries for a single transmission.

• Microsoft IIS log file format Information is written to a comma- delimited ASCII text file. Once the data is written it cannot be changed, and the log format is not customizable. There are usually multiple records for a single transmission.

• NCSA common log file format Information is written to an ASCII text file in the National Center for Computing Applications (NCSA) format. Once the data is written, it cannot be changed, and the log format is not customizable. There are usually multiple records for a single transmission.

• ODBC logging Information is written to an open database connectivity (ODBC)-compliant database.

On the General tab, you can also limit the number of users who connect to this virtual server by selecting the Limit Number Of Connections To check box and then entering the desired limit. You can also limit idle connections to a certain number of minutes to conserve system resources.

Finally, the General tab (Figure 20-9) allows you to change the IP address to which the virtual server is bound without creating a new virtual server. If you need to change the port number, click the Advanced button, and then make your changes in the Advanced dialog box (Figure 20-10). You can also assign multiple combinations of IP address and port number to the same virtual server, which gives you maximum administrative flexibility. Selecting All Unassigned allows the virtual server to respond to any requests that are not handled by other services.

Figure 20-10: Changing the port number of a virtual server.

Enabling message filtering The Filter Enabled column in the Advanced dialog box indicates whether message filtering is enabled. You can enable filtering by selecting the Apply Filter options in the Identification dialog box (Figure 20 10), which you display by clicking either Add or Edit in the Advanced dialog box. When message filtering is enabled on an SMTP virtual server, the server will not accept e-mail from any domain on the message filtering list. Message filtering is defined globally but is enabled for individual IP addresses. Before you can enable message filtering, you must first create a message filter list (Figure 20-11). You can choose to filter from the senders list, the recipients list, or a connections list.

Figure 20-11: Connection Filtering tab in properties of the Global Settings/Message Delivery object.

To create a message filter list, open the Exchange System snap-in, and select the Global Settings container. Right-click Message Delivery, and choose Properties. You’ll see three filtering tabs: Recipient, Sender, and Connection. Select the filtering types you want to configure, and then select the tab to enter your rules.

Connection Filtering

Exchange 2003 supports connection filtering based on Real-Time Black Lists (RBLs). This feature uses externally-based services to identify three categories of offenders based on their IP addresses: unsolicited e-mail, dial-up user account lists, and servers that open for relay. Exchange allows you to check incoming e-mail, resolve the originating domain name to an IP address, and then check that IP address and/or domain name to an RBL. If a match is found, the SMTP server issues a “550 5.x.x” error in response to the RCPT TO: command.

Connection filters are implemented using rules. These rules include the ability to do the following:

• Set the rule display name

• Enter the DNS suffix of the RBL provider

• Return a custom error message instead of the default 550 error message

• Customize the return status code from the RBL provider

• Disable the rule without deleting it

• Enter exceptions to all rules using global settings

• Configure exceptions to all rules using a separate exceptions list

You configure your connection filtering rules on the Connection Filtering tab in the properties of the Global Settings/Message Delivery object (Figure 20-11).

To create a connection filter, click the Add button to invoke the Connection Filtering Rule dialog box (Figure 20-12) on the Connection Filter tab. Type a display name for the filter, and then type the DNS suffix of the RBL provider. Enter a custom error message for the sender or select the Return Status Code by clicking on the Return Status Code button.

Figure 20-12: Connection Filtering Rule dialog box.

When an e-mail sender is found to be in one of the offending categories defined by Black List (or in a subcategory to which you have subscribed), a default error message is returned to the sender. You can customize the error message as follows:

• %0 = connecting IP address

• %1 = Rule Name

• %2 = the RBL Provider

For example, suppose you wanted your error message to read as follows:

You have sent an e-mail message to <my_company>. Your IP address <IP Address> was blocked by <RBL Provider> and is considered unsolicited e-mail.

You would enter the following in the Custom Error Message To Return field (Figure 20-12):

You have sent an e-mail message to <My_Company>. Your IP address %0 was blocked by %2 and is considered unsolicited e-mail.

Return Status Codes (RTC) work with the 127.x.x.x IP address range to give your e-mail server a status report on the e-mail that is received. When your e-mail server receives an e-mail, Exchange contacts the RBL provider. The RBL provider uses the sender’s information in the headers of the e-mail to check for an A (Address) record in DNS for the originating e-mail server. A reverse lookup is initiated and, if the IP address is found on the provider’s list, the RBL provider returns a 127.0.0.x status code that indicates the e-mail is coming from an offending IP address. The code also indicates the type of offense. For instance, if the IP address returned is 127.0.0.3, and your RBL provider has indicated that a “3” in the last octet, the e-mail is coming from a known source of unsolicited e-mail. When that status code is returned, Exchange filters the e-mail.

The RBL provider might return a bitmask, which is a return message that can serve more than one purpose. For instance, IP addresses might be a member of more than one list. If “3” means unsolicited e-mail and “4” means a known relay server, a return status code of “7” would indicate that the IP address is a member of both lists. However, you can enter a bitmask for the return status codes, as Figure 20-13 suggests. If you enter 0.0.0.4, and your RBL has indicated that “4” is for known relay servers, this rule filters only for IP addresses that are known SMTP relay servers. Furthermore, if your RBL provider has indicated that a “3” is the return status code for known sources of unsolicited e-mail, a bitmask of 0.0.0.4 will not filter unsolicited e-mail. Bitmasks are used to filter for a specific type of IP address. You do have the option to create multiple rules, each with an individual bitmask that filters for a specific type of IP address. Note that a bitmask checks only against a single value. If you set a bitmask value that is returned when an IP address appears on two lists, the mask will match only IP addresses that satisfy both settings. For example, if you set a bitmask of 0.0.0.7, the IP address will be filtered only when the IP address appears on the 0.0.0.3 and 0.0.0.4 lists.

Figure 20-13: Return Status Code dialog box.

You have three choices when deciding what type of return status code you want. We’ve already discussed one option: Match Filter Rule To The Following Mask. Another option is Match Filter To Any Return Code. This selection is the most broad; any return status code will invoke this filter rule. Your last option is Match Filter Rule To Any Of The Following Reponses, which allows you to enter custom bitmasks supplied by your RBL provider.

Your RBL provider will give you all the codes you need for work with their system so that Exchange can filter for the IP addresses you specify by entering multiple rules in this area.

In the Connection Filtering Rule dialog box, you can also specify exceptions to the connection filtering rules, which means that you can force the acceptance of e-mail from blacklisted sources or reject e-mail from sources who are not blacklisted. You might use the exceptions feature when you want to allow delivery of messages to specific recipients, such as the postmaster, or from a specific server, regardless of the RSC from your provider.

After you create your filter rules, you must apply them to a specific SMTP VS. You accomplish this in the properties of the SMTP VS. On the General tab, click the Advanced button to display the Advanced dialog box, and then click the Edit button to display the Identification dialog box (Figure 20-14). Here you select the type of filtering for this particular VS. You can select from any of the three types of filtering that are available in Exchange Server 2003.

Figure 20-14: Selecting the type of filtering for a particular VS.

Recipient Filtering

Recipient filtering allows you to block an e-mail message based on its destination. You can block based on invalid recipients in your organization or develop a recipient filter list for outbound e-mail. (Note that recipient filtering only applies to anonymous connections. Authenticated users and Exchange servers bypass recipient filtering.)

You can block inbound e-mail based on invalid Active Directory user lookups, meaning that the target user doesn’t exist in your organization. But you can also block inbound e-mail based on who has permissions to send e-mail to that user.

To enter a recipient for the recipient filtering list, click the Add button on the Recipient Filter tab in the properties of the Message Delivery global object (Figure 20-15). To filter all messages for a particular domain, enter *@<domain_name>.com or just @<domain_name>.com. Otherwise, enter the specific e-mail address that should be included in this filter list.

Figure 20-15: Entering a recipient for the recipient filtering list.

To filter outbound recipients, select the Filter Recipients Who Are Not In The Directory check box. Doing so filters e-mail addresses that are not in your Active Directory. You must consider two issues when choosing this option. First, Exchange will perform filtering only on domain names for which it is authoritative. You’ll need to set this in the Recipient Policies global object. Second, enabling this feature causes Exchange to return different status codes for valid and invalid recipients. E-mail abusers can use such codes to discover valid e-mail addresses in your organization.

After you create the recipient filter, be sure to apply it to the SMTP VS. Otherwise, it won’t do you much good!

Sender Filtering

Sender filtering filters messages based on the sender of the message. On the Sender Filtering tab (Figure 20-16), enter the e-mail addresses you want to filter, or configure individual options. Note that you can block based on entire domain names as well by entering the individual domain name as follows: *@<domain_name.com>.

Figure 20-16: Filtering messages based on the sender of the message.

If you choose the Archive Filtered Messages option, each message is archived. Be certain you want to select this option because the archive can fill up rather quickly. And since clearing messages from the archive is not a routine matter, you’ll need to schedule the manual removal of them from the archive on a regular basis.

You can also filter messages that have a black FROM field. Some automated junk e-mail scripts and sources of unsolicited e-mail do not populate this field. This action is not turned on by default but in most cases should be.

The Drop Connection If Address Matches Filter options is selected by default. This option forces Exchange to immediately drop the TCP connection when a sender’s address matches an address on the filter.

Finally, the Accept Messages Without Notifying Sender Of Filtering option (dimmed in Figure 20-16) ensures that the originators of messages being filtered are not notified with an NDR (non-delivery Report) that their messages were not delivered. If you have a large amount of spam e-mail, selecting this option can improve server performance.

Note

Any changes you make to a virtual server won’t take effect for a few minutes because the metabase update service needs time to replicate the changes to the IIS metabase. This update service replicates changes made in Active Directory to the IIS metabase, allowing you to make changes to a virtual server without a permanent connection to each system involved in the update.

Configuring access properties On the Access tab (Figure 20-17) of the virtual server’s property sheet, you’ll find a number of important configuration options. Clicking the Authentication button displays a dialog box that allows you to choose Basic authentication, anonymous access, Integrated Windows Authentication (IWA), or a combination of these options. You can also specify here that Transport Layer Security (TLS) encryption be enforced based on the domain name that you enter.

Figure 20-17: Access tab of a virtual server’s property sheet.

Note

Integrated Windows Authentication requires a valid Windows Server 2003 user name and password. It authenticates users by relaying their information directly to the domain controller. Once users are authenticated, they access objects in their security context. IWA was called Windows NT Challenge/Response in IIS 4.

The Secure Communication area of the Access tab has two buttons: Certificate and Communication. If a certificate is not yet installed on this server, you can create a default one, using a wizard that you start by clicking the Certificate button. Once a valid certificate is installed, you can require that communication take place over a secure channel. You do so by clicking the Communication button. In the Security dialog box (Figure 20-18), you can require both secure channel communication and 128-bit encryption. If external users who need high security are sending e-mails to this virtual server, consider using both encryption and certificates.

Figure 20-18: Configuring security requirements.

By clicking the Connection button in the Connection Control area of the Access tab (Figure 20-17), you can specify the domain name or IP address of computers to be given access to or excluded from the virtual server (Figure 20-19).

Figure 20-19: Connection dialog box.

Finally, clicking the Relay button in the Relay Restrictions area of the Access tab allows you to indicate which SMTP servers can relay messages through this virtual server (Figure 20-20). You can specify the servers by domain name or IP address. You can also establish an exception to these restrictions by selecting the Allow All Computers Which Successfully Authenticate To Relay, Regardless Of The List Above check box. This option could be used to allow vendors outside your company (each with their own SMTP domain name) to use your Exchange server as their messaging relay to the Internet once they authenticate to prove they have permission to do so.

Figure 20-20: Relay Restrictions dialog box.

You can also allow a select group of users to relay e-mail to the Internet by configuring the Grant Or Deny Relay Permissions To Specific Users Or Groups. To do this, first clear the Allow All Computers Which Successfully Authenticate To Relay check box, click the Users button, and then enter your configuration values. Note that the default is to allow users to submit e-mail. But you can enter another Active Directory group and give those users the Relay permission (Figure 20-21).

Figure 20-21: Permissions For Submit And Relay dialog box.

You can restrict relay abilities based on a single IP address, a range of IP addresses, or a domain name (Figure 20-22). You must choose one method per entry in the restrictions list, so if you want to restrict message relay based on both IP address and domain name, you’ll need to make two entries.

Figure 20-22: Adding a computer to the relay restrictions list.

Configuring messaging limits and badmail behavior The Messages tab of the property sheet (Figure 20-23) for a virtual server holds configuration choices governing message size limits and badmail behavior. Badmail is defined as e-mail that cannot be delivered or returned. The default directory for badmail is \Exchsrvr\mailroot\vsi #\badmail (where vsi # is the specific virtual server; for instance, vsi 1 is the default SMTP virtual server). You can change the location of the badmail directory and the queue directory by clicking on the Browse button and then selecting a different location. Usually, when a message is undeliverable, the sender receives a non-delivery report (NDR). You can also designate that a copy of all NDRs be sent to the e-mail address of your choice.

Figure 20-23: Messages tab of a virtual server’s property sheet.

Caution

Do not select the M: drive for your badmail directory. Doing so will cause conflicts with Exchange administration and transport services and will cause messages to stop flowing.

If you have another e-mail server in your organization, such as a UNIX-based server, that handles the same domain as your SMTP virtual server, enter the host name for that server in the Forward All Mail With Unresolved Recipients To Host text box. When your Exchange server receives e-mail for a user that it can’t resolve, it will forward the e-mail to this host. For example, if the SMTP virtual server and a UNIX e-mail server both serve the trainsbydave.com domain, Exchange Server might receive e-mail intended for UNIX users. When Exchange Server can’t find these users, it will know to forward these messages to the designated host in the other system.

Configuring delivery information The Delivery tab of the virtual server’s property sheet lets you configure outbound e-mail retry and expiration values as well as outbound connection values and security information. If this virtual server will be connecting to another virtual server, be sure to make the outbound security settings match the inbound security settings on the other virtual server.

The Advanced Delivery dialog box (Figure 20-24), displayed by clicking Advanced on the Delivery tab, has several interesting options. The Masquerade Domain option allows you to indicate a different domain name to be placed in both the Mail From and From fields of all outgoing messages. The Mail From field is found within the SMTP message header and denotes the domain the message came from, whereas the From field is found in the body of the message and denotes who the message is from. When a message’s Mail From field is modified, the modification remains through delivery.

Figure 20-24: Advanced Delivery dialog box.

For instance, if your server is hosting the sales.hr.trainsbydave.com domain inside of the trainsbydave.com domain, the default entry in the Mail From field would be sales.hr.trainsbydave.com. If you would like to change this to trainsbydave.com, enter that information in the Masquerade Domain field. All outgoing messages will then appear to come from the trainsbydave.com domain, and any NDRs will be sent back to the trainsbydave.com domain.

In contrast, the From field, which the Masquerade Domain field also modifies to denote (in our example) the alternate domain of trainsbydave.com, applies only to the first hop. This means that if the message has to pass through a number of messaging systems to reach its destination, it will revert to its original domain name after the first hop. The Maximum Hop Count option, which sets the maximum number of Received header lines that an SMTP server will accept on incoming messages before returning an NDR to the message originator, is configured here too.

Selecting the Perform Reverse DNS Lookup On Incoming Messages option causes Exchange 2003 Server to attempt to verify that the client’s IP address matches the domain name submitted by the client in the HELO/EHLO command. If the reverse DNS lookup is successful, the Received header is not changed. If it is unsuccessful, the Received header indicates “unverified” after the IP address. If reverse DNS lookups are affecting performance, consider clearing this check box. This feature is disabled by default.

Troubleshooting SMTP

There are several ways to troubleshoot problems with SMTP. First, make sure that the virtual server settings are correct. For instance, be sure that the IP address and port number assignments do not conflict with those of other virtual servers. Second, enable logging on the SMTP server, and then read the log files to see whether an error code or error reply has been recorded. This information can help you pinpoint the cause of your problem. Finally, use Telnet to connect to the SMTP server, and then send the SMTP commands to the server to see its response. This is the most granular and effective way to troubleshoot an SMTP server. For example, if you want to test an Exchange server to ensure that it is not open for relay, follow these steps:

1. Use the command prompt to open a Telnet session by entering the following command: open <server_name> 25 (Figure 20-25). You will receive information from the SMTP server indicating the server name, the e-mail service it is running, and the version along with the date and time the message was generated (Figure 20-26).

   
   Figure 20-25: Telnet command to open a Telnet session to SMTP server Tucson.trainsbydave.com over port 25.

   
   Figure 20-26: Response from the Tucson server allowing the Telnet connection.

2. Enter the EHLO command. You’ll receive the list of commands supported by the server.

3. Enter the following command: mail from: <[e-mail]>

4. Enter this command: rcpt to: <your_e-mail_address>

   If your Exchange server is not open for relaying, you’ll receive a 550 5.7.1 error message: “Unable to relay for <your_e-mail_address>” (Figure 20-27).

   
   Figure 20-27: Telnet session using commands to test for abilities to relay through the Tucson server.

You can open a Telnet session to any Exchange server and then use the SMTP commands and the Extended SMTP commands to test the SMTP service on that server. Getting a good handle on how to use these commands will help you troubleshoot the SMTP service when you suspect messages are not being transferred correctly.