Transport and Message Flow Features of Exchange Server 2003

 

Microsoft® Exchange Server 2003 introduces several new features and functionality to improve transport and message flow. This topic explains the following:

  • Link state improvements
    This section explains how link state improvements reduce the amount of link state information that is replicated throughout the Exchange organization, thereby reducing the negative effect on performance.
  • Cross-forest authentication configuration
    Because Exchange 2003 prevents spoofing or forging e-mail addresses, you must perform specific configuration steps to enable cross-forest authentication. This section shows you how to enable cross-forest authentication.
  • Internet Mail Wizard
    Exchange 2003 provides a new version of Internet Mail Wizard to guide you through configuring Internet mail delivery in your organization. This section explains how to use the wizard to set up Internet mail delivery.
  • Delivery status notification (DSN) diagnostic logging and codes
    Exchange 2003 now provides diagnostic logging for delivery status notifications (DSNs) and implements some new DSN codes. This section explains how to configure DSN diagnostic logging and explains the new DSN codes available in Exchange 2003.
  • Support for moving X.400 (MTA) and SMTP queue directories
    In Exchange 2003, you can use Exchange System Manager to change the location where your SMTP and X.400 queue data is stored. This section explains how to use Exchange System Manager to move your queue directory.
  • Connection filtering
    Exchange 2003 supports connection filtering based on block lists. This section explains how connection filtering works, and how you can set it up on your Exchange server.
  • Recipient filtering
    Exchange 2003 also supports recipient filtering so that you can filter e-mail messages that are addressed to users who are not in the Microsoft Active Directory® directory service or e-mail messages that are addressed to well-defined recipients indicative of unsolicited commercial mail.
  • New in SP2: Sender ID filtering
    In Exchange Server 2003 SP2, you can use Sender ID filtering features. Sender ID is an e-mail industry initiative that you can use to provide more protection against unsolicited commercial e-mail (UCE) and phishing schemes. Specifically, Sender ID helps prevent domain spoofing.
  • New in SP2: Intelligent message filtering
    In Exchange Server 2003 SP2, Intelligent message filtering is now installed when you install Exchange Server 2003 SP2.
  • How enabled filters are applied
    This section explains how filters and restrictions are applied during an SMTP session.
  • Improved ability to restrict submission to an SMTP virtual server
    This section explains how you can restrict submissions based on security groups in Exchange 2003.
  • Improved ability to restrict relaying on an SMTP virtual server
    This section explains how you can restrict relaying based on security groups in Exchange 2003.

Exchange 2003 also provides the following other features that enhance transport and mail flow:

  • A new type of distribution group that is named query-based distribution groups allow you to use an LDAP query to dynamically build membership in the distribution groups. For more information, see "Query-Based Distribution Groups" and "Improved Message Tracking" in Administration Features in Exchange Server 2003.

  • You can now set restrictions on who can send mail to a distribution list. For more information, see "Improved Ability to Restrict Submissions to Users and Distribution Lists (Restricted Distribution Lists)" in Administration Features in Exchange Server 2003.

  • You can now track messages after categorization (which is the phase where users are located and distribution groups are expanded into individual recipients) and during the routing process. You can also use Exchange System Manager to move message-tracking logs. For more information, see "Improved Message Tracking" in Administration Features in Exchange Server 2003.

  • Improvements to Queue Viewer. More queues are exposed, so you can more easily diagnose problems with mail flow. For more information, see "Enhancements to Queue Viewer" in Administration Features in Exchange Server 2003.

  • With the archiving feature available on a mailbox store, you can archive all recipients, including those on the Bcc line. For more information, see "Including Bcc Recipients in Archived Messages" in Administration Features in Exchange Server 2003.

Exchange uses link state routing to determine the best method for sending messages between servers, based on the current status of messaging connectivity and cost. If no alternate path for the message exists, or if there is an oscillating connection (a connection that is intermittently available and unavailable), Exchange 2003 improves how link state information is communicated. Specifically, Exchange 2003 reduces link state traffic by attempting to determine if the connector state is oscillating or if no alternate path exists; if either of these conditions exists, Exchange suppresses the link state information.

In Exchange 2003, even if no alternate path exists for a link, the link state is always marked as up (in service). Exchange no longer changes the link state to unavailable if no alternate path exists. Instead, Exchange simply queues mail for delivery and sends it when the route becomes available. This change enhances performance because it reduces the propagation of link state information.

Another significant improvement to link state routing is how Exchange 2003 handles oscillating connections. Exchange 2003 reviews the link state queue, and if there are multiple conflicting state changes in a given interval for a connector, the connector is considered an oscillating connection, and its link state remains up (in service). It is better to leave an oscillating connector up than to continually change the link state. This reduces the amount of link state traffic that is replicated between servers.

Configuring Cross-Forest SMTP Mail Collaboration

To prevent spoofing (forging identities), Exchange 2003 requires authentication before a sender's name is resolved to its display name in the global address list (GAL). Therefore, in an organization that spans two forests, a user who sends mail from one forest to another forest is not authenticated. Furthermore, the user's name is not resolved to a display name in the GAL, even if the user is a contact in the destination forest.

To enable cross-forest mail collaboration in Exchange 2003, additional configuration steps are required to resolve contacts outside your organization to their display names in Active Directory. You have two options to enable the resolution of these contacts:

  • Option 1 (recommended)   Use authentication so that users who send mail from one forest to another are authenticated users, and their names are resolved to their display names in the GAL.

  • Option 2   Restrict access to the SMTP virtual server that is used for cross-forest collaboration, and then configure Exchange to resolve anonymous e-mail. This configuration is supported, but not recommended. By default, in this configuration, the Exch50 message properties, which are the extended properties of a message, are not persisted when mail is sent from one forest to another.

To understand the benefits of configuring cross-forest mail collaboration, consider the following scenarios of anonymous mail submission and cross-forest authenticated mail submission.

Scenario: Anonymous Mail Submission

E-mail addresses are not resolved if the submission is anonymous. Therefore, when an anonymous user who attempts to spoof (forge) an internal user's identity sends mail, the return address does not resolve to its display name in the global address list (GAL).

Example:

Kim Akers is a legitimate internal user at Northwind Traders. Her display name in the GAL is Kim Akers, and her e-mail address is kim@northwindtraders.com.

To send mail, Kim must be authenticated. Because she is authenticated, the intended recipients of Kim's mail see that the sender is Kim Akers. Additionally, the properties of Kim Akers are displayed as her GAL entry. However, if Ted Bremer attempts to forge Kim's address by using kim@northwindtraders.com in the From line and then sending the mail to the Exchange 2003 server at Northwind Traders, the e-mail address is not resolved to Kim's display name because Ted did not authenticate. Therefore, when this e-mail message displays in Microsoft Office Outlook®, the sender address appears as kim@northwindtraders.com; it does not resolve to Kim Akers, as authenticated mail from Kim does.

Scenario: Cross-Forest Mail Delivery

Consider a company that spans two forests: the Adatum forest and the Fabrikam forest. Both these forests are single domains forests with domains of adatum.com and fabrikam.com respectively. To allow cross-forest mail collaboration, all users in the Adatum forest are represented as contacts in the Fabrikam forest's Active Directory. Likewise, all users in the Fabrikam forest are represented as contacts in Adatum forest's Active Directory.

If a user in the Adatum forest sends mail to Fabrikam forest, and the mail is submitted over an anonymous connection, the sender's address is not resolved, despite the fact the sender exists as a contact in the Active Directory and in the Outlook GAL. This is because a user in the Adatum forest is not an authenticated user in Fabrikam forest.

Example:

Kim Akers is a mail user in the Adatum forest—her e-mail address is kim@adatum.com, and her Outlook GAL display name is Kim Akers. Adam Barr is a user in the Fabrikam forest—his e-mail address is abarr@fabrikam.com, and his Outlook GAL display name is Adam Barr. Because Adam is represented as an Active Directory contact in the Adatum forest, Kim can view Adam's e-mail address and resolve it to the display name of Adam Barr in the Outlook GAL. When Adam receives mail from Kim, Kim's address is not resolved; instead of seeing Kim's display name as it appears in the GAL, Adam sees her unresolved e-mail address of kim@adatum.com. Because Kim sent mail as an anonymous user, her e-mail address did not resolve. Although Kim is authenticated when sending mail, the connection between the two forests is not authenticated.

To ensure that senders in one forest can send mail to recipients in another forests, and to ensure that their e-mail addresses resolve to their display names in the GAL, you should enable cross-forest mail collaboration. The following sections explain the two options available for configuring mail collaboration between two forests.

Enabling Cross-Forest Authentication

To enable cross-forest SMTP authentication, you must create connectors in each forest that uses an authenticated account from the other forest. By doing this, any mail that is sent between the two forests by an authenticated user resolves to the appropriate display name in the GAL. This section explains how to enable cross-forest authentication.

Using the example of the Adatum forest and the Fabrikam forest (see the "Cross-Forest Mail Delivery" scenario earlier in this topic), follow these steps to set up cross-forest authentication:

  1. Create an account in the Fabrikam forest that has Send As permissions. (For all users in the Adatum forest, a contact is located in the Fabrikam forest as well; therefore this account allows Adatum users to send authenticated mail.) Configure these permissions on all Exchange servers that will accept incoming mail from Adatum.

  2. On an Exchange server in the Adatum forest, create a connector that requires authentication using this account to send outbound mail.

Similarly, to set up cross-forest authentication from the Fabrikam forest to Adatum forest, repeat these steps, creating the account in Adatum and the connector in Fabrikam. For detailed instructions, see "How to Enable Cross-Forest SMTP Authentication" in the Exchange Server 2003 Deployment Guide.

Enabling Cross-Forest Collaboration by Resolving Anonymous Mail

Another way you can configure Exchange to resolve contacts outside your organization to their display names in Active Directory is to configure Exchange to resolve anonymous e-mail. Assume that your company spans two forests, from the Adatum forest to the Fabrikam forest.

Important

Configuring Exchange servers to resolve anonymous mail submissions lets unscrupulous users submit messages with a falsified return address. Recipients are not able to differentiate between authentic mail and spoofed mail. To minimize this possibility, ensure that you restrict access to the SMTP virtual server to the IP addresses of your Exchange servers.

Follow these steps to resolve contacts for Adatum users to their display names in the Fabrikam forest:

  1. Create a connector in the Adatum forest that connects to the Fabrikam forest.

  2. On the receiving bridgehead server in the Fabrikam forest, restrict access to the SMTP virtual server by IP address. By doing this, you can ensure that only servers from the Adatum forest can send mail to this server.

  3. On the SMTP virtual server that hosts the connector, enable the Resolve anonymous e-mail setting.

  4. Change a registry key to ensure that the extended message properties (Exch50 properties) are persisted across the forests. Otherwise, you can lose important message information.

After you complete these steps, all users who send mail from the Adatum forest to the Fabrikam forest will resolve to their display names in the Fabrikam GAL. Next, you need to repeat steps 1 through 3 for the Fabrikam forest.

The following procedures show you how to:

  • Set up a connector in the Adatum forest to Fabrikam.

  • Restrict access to the receiving bridgehead server in the Fabrikam forest

  • Enable anonymous e-mail resolution on the SMTP virtual server on the receiving bridgehead server in order to resolve Adatum contacts in the Fabrikam forest.

In a production environment, you would then repeat this process to configure the resolution of Fabrikam contacts in the Adatum forest.

Step 1: Creating a Connector in the Connecting Forest

First, you need to create a connector in the connecting forest. For detailed instructions, see How to Create a Connector in a Connecting Forest.

For detailed instructions about how to create the account used for cross-forest authentication, see "How to Create the Account Used for Cross-Forest Authentication" in the Exchanger Server 2003 Transport and Routing Guide.

Exchange will now route all mail destined to fabrikam.com (the Fabrikam forest) through this connector.

Step 2: Restricting IP Addresses on the Receiving Bridgehead Server

After you create the connector in the Adatum forest (the connecting forest) you must restrict access to the receiving bridgehead server. You do this by allowing only the IP address of the connecting servers in the Adatum forest to send mail to the receiving bridgehead server in the Fabrikam forest.

For detailed instructions, see "How to Restrict Access by IP Address on the Receiving Bridgehead Server" in the Exchange Server 2003 Transport and Routing Guide.

Step 3: Resolving Anonymous Mail on the SMTP Virtual Server

After you have restricted access to the receiving bridgehead server, you must configure the SMTP virtual server on this bridgehead to resolve anonymous e-mail addresses.

For detailed instruction, see "How to Configure an SMTP Virtual Server to Resolve Anonymous E-mail Addresses" in the Exchange Server 2003 Transport and Routing Guide.

Step 4: Enabling Registry Key to Persist Message Properties Across Forests

As explained earlier, when messages are sent anonymously across forests, the extended message properties on a message are not transmitted. For single companies that implement a cross-forest scenario, these message properties must be transmitted because information about the message can be lost. For example, the SCL property, an extended Exchange property contains a spam rating that is generated by third-party solutions. This property is not transmitted when mail is sent anonymously. So if a third-party anti-spam solution is deployed in the Adatum forest, and a message received in this forest is destined to a recipient in the Fabrikam forest, the third party solution stamps the SCL property on the message; however, when the message is delivered to the Fabrikam forest, the extended property containing the spam rating is not persisted.

To ensure that the extended message properties are transmitted across forests when you send mail anonymously, you must enable a registry key on the receiving bridgehead server.

To configure Exchange to accept the extended message properties, you can enable a registry key on the receiving bridgehead server or on the SMTP virtual server that resides on the bridgehead. Enabling the registry key on the Exchange server configures all SMTP virtual servers on the Exchange server to accept extended properties.

Configuring the Exchange Server to Accept Extended Message Properties on Anonymous Connections

Use the following procedure to configure the Exchange server to accept extended properties on anonymous connections. If your Exchange server functions solely as the bridgehead server for cross-forest communication, you may want to configure this setting at the server level. If you have other SMTP virtual servers on this Exchange server, consider setting this registry key on the SMTP virtual server only.

Note

If you enable this registry key on an Exchange server, the setting applies to all SMTP virtual servers on the Exchange server. If you want to configure a single SMTP virtual server with this setting, enable the registry key on the SMTP virtual server.

Warning

Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data.

For detailed instructions, see "How to Enable an Exchange Server to Accept Message Extended Properties that Are Sent Anonymously" in the Exchange Server 2003 Transport and Routing Guide.

Configuring an SMTP Virtual Server to Accept Extended Message Properties Sent Anonymously

Use the following procedure to configure the SMTP virtual server on the Exchange server to accept extended properties

For detailed instructions, see "How to Enable an SMTP Virtual Server to Accept Message Extended Properties that Are Sent Anonymously" in the Exchange Server 2003 Transport and Routing Guide.

Internet Mail Wizard

In Exchange Server version 5.5, Internet Mail Wizard guided administrators through the process of setting up Internet mail. Exchange 2003 implements a version of Internet Mail Wizard to help you configure Internet mail connectivity with Exchange 2000 Server or Exchange Server 2003. Internet Mail Wizard is intended primarily for small and medium companies with less complex environments than large enterprise companies.

The wizard guides you through configuring your Exchange server to send and receive Internet mail. It creates the necessary SMTP connector for outgoing Internet mail and configures your SMTP virtual server to accept incoming mail. If you already set up SMTP connectors or created additional SMTP virtual servers on your Exchange server, you cannot run Internet Mail Wizard unless you revert your server configuration to its default state.

Note

Internet Mail Wizard can only configure Internet mail for Exchange 2000 Server or a later version. If you are running previous versions of Exchange, these servers can still send mail to or receive mail from the Internet, but you cannot use Internet Mail Wizard to configure them for Internet mail.

When Internet Mail Wizard runs, it creates a log file (Exchange Internet Mail Wizard.log) of all the configuration changes it makes, including whether or not these changes were successful. The wizard saves this log file to the My Documents folder of the user who runs the wizard.

The following sections explain how to use Internet Mail Wizard to:

  • Configure an Exchange server to send Internet mail

  • Configure an Exchange server to receive Internet mail

  • Configure an Exchange server or servers to send and receive Internet mail

  • Configure a dual-homed Exchange server for Internet mail

Configuring an Exchange Server to Send Internet Mail

When you configure an Exchange server to send Internet mail, Internet Mail Wizard configures the selected server as an outbound bridgehead server. It creates a connector on this server to send mail to the Internet addresses you specify.

For detailed instructions, see How to Run Internet Mail Wizard and Configure Your Server to Send Internet Mail.

Configuring an Exchange Server to Receive Internet Mail

After you run Internet Mail Wizard, the Exchange server will accept all Internet mail for the SMTP domains that you specify.

For detailed instructions, see How to Run Internet Mail Wizard and Configure Your Server to Receive Internet Mail.

Configuring an Exchange Server to Send and Receive Internet Mail

After you run Internet Mail Wizard, the Exchange server will send and receive all Internet mail according to the configuration you specify.

For detailed instructions, see How to Run Internet Mail Wizard and Configure Your Server to Send and Receive Internet Mail.

Configuring a Dual-Homed Exchange Server for Internet Mail

After you run Internet Mail Wizard, the Exchange server will send and receive all Internet mail according to the configuration you specify.

For detailed instructions, see How to Run Internet Mail Wizard on a Dual-Homed Server.

DSN Diagnostic Logging and DSN Codes

In Exchange 2003, the following improvements have been made to delivery status notifications (DSNs).

  • A new DSN logging category is available.

  • New DSN codes are included to help troubleshoot message flow issues.

Configuring DSN Diagnostic Logging

You can now configure diagnostic logging for DSNs, also known as non-delivery reports (NDRs).

For detailed instructions, see How to Configure Diagnostic Logging for DSN.

DSN Codes Available in Exchange Server 2003

The following table lists the DSN messages implemented in Exchange 2003 for transport and routing.

New delivery status notifications available in Exchange 2003

DSN Code Cause Solution

4.2.2

In Exchange 2000, this delivery status notification is generated when the recipient's mailbox exceeds its storage limit.

On Windows® 2000 and Microsoft Windows Server™ 2003, this message is generated when the storage size of the drop directory (a directory where messages can be placed for delivery) exceeds the SMTP virtual server disk quota. The disk quota of the SMTP virtual server is 11 times the maximum message size on the virtual server. If no maximum size is specified, the disk quota defaults to 22 MB. If the disk space is within one maximum message size of the quota or if the disk space reaches 2 MB is no maximum message is defined, Exchange assumes that the incoming message will exceed the disk quota, and then issues the DSN.

Check the mailbox storage and the queue storage quota limit.

4.4.9

This indicates a temporary routing error or bad routing configuration. Possible causes are:

  • Someone configured an SMTP connector using DNS (rather than a smarthost) and added a non-SMTP address space, such as an X.400 address, to this connector.

  • Someone created a routing group, and a recipient in this routing group was supposed to receive mail. A routing group connector using DNS was used to bridge the routing group, and then this administrative or routing group was removed. Therefore, any mail sent to this routing group was sent in the MSGWIA.X500 format (the address encapsulation used for non-SMTP addresses); DNS does not recognize this format.

Routing detects these situations, and Exchange returns DSNs.

  • To remedy the first scenario, configure the SMTP connector to use a smarthost, instead of DNS, to resolve the non-SMTP address space.

  • To remedy second scenario, ensure that you moved all users in the removed administrative group or routing group to a valid group.

5.3.0

Exchange 2003 can operate without the message transfer agent (MTA). If mail was mistakenly sent to the MTA, then Exchange returns this DSN to the sender. This condition is enforced only if you have disabled the MTA service and used specific registry settings to disable the MTA/Store Driver. A default configuration strands the misrouted mail on the MTA queues.

Check your routing topology. Use the Winroute tool to ensure that the routes are correctly replicated between servers and routing groups.

5.7.1

General access denied, sender access denied—The sender of the message does not have the privileges necessary to complete delivery.

Possible causes include:

  • The sender of the message does not have the privileges necessary to complete delivery.

  • You are trying to relay your mail through another Exchange 2000 server, and the server does not permit you to relay. The remote server returns a 5.7.1 code.

  • The recipient may have mailbox delivery restrictions enabled (for example, if a recipient's mailbox delivery restriction is configured to receive mail from a distribution list only, non-member's mail is rejected, and this DSN code is returned).

  • New in Exchange 2003: An anonymous user tried to send mail to recipients or distribution lists that accept mail from an authenticated SMTP session only.

Check system privileges and attributes for the contact and retry the message. Also, for other potential known issues, ensure that you are running Exchange 2000 Service Pack 1 or later. In Exchange 2003, check the permissions on the distribution list to see if it is a restricted distribution list.

Moving the X.400 (MTA) and SMTP Queue Directory Locations

Exchange 2003 allows you to change the queue directory locations for SMTP virtual servers and the X.400 protocol.

For detailed instructions, see How to Move X.400 (MTA) Queue Data and How to Move SMTP Queue Data.

Connection Filtering

Exchange Server 2003 supports connection filtering based on block lists. Connection filtering leverages external-based services that list known sources of unsolicited e-mail sources, dial-up user accounts, and servers open for relay (based on IP addresses). Connection filtering compliments third-party content filter products. This feature allows you to check an incoming IP address against a block list provider's list for the categories you want to filter. If a match is found on the block list provider's list, SMTP issues a "550 5.x.x" error in response to the RCPT TO command, and a customized error response is issued to the sender. (The RCPT TO command is the SMTP command that the connecting server issues to identify the intended message recipient.) Furthermore, you can use several connection filters and prioritize the order in which each filter is applied.

With connection filtering, you can do the following:

  • Set up connection filtering rules that check with a block list service provider for the following:

    • IP addresses of known senders of unsolicited commercial e-mail

    • Servers configured for open relay

    • Dial-up user account lists

  • Configure global accept and deny lists. A global accept list is a list of IP addresses from which you will always accept mail. A global deny list is a list of IP addresses from which will always deny mail. You can use global accept and deny lists with or without using a block list service provider.

  • Configure a recipient address as exception to all connection filtering rules. You can configure a recipient address as an exception to all connection-filtering rules. When mail is sent to this address, it is automatically accepted, even if the sender appears on a block list.

How Connection-Filtering Rules Work

When you create a connection-filtering rule, SMTP uses this rule to perform a DNS lookup to a list provided by a third-party block list service. The connection filter matches each incoming IP address against the third-party block list. The block list provider issues one of two responses:

  • host not found   Indicates that the IP address is not present on its block list.

  • 127.0.0.x   A response status code indicating that a match for the IP address was found in the list of offenders. The x varies, depending on your block list provider.

If the incoming IP address is found on the block list, SMTP returns a 5.x.x error in response to the RCPT TO command (The RCPT TO command is the SMTP command that the connecting server issues to identify the intended message recipient.)

You can customize the response that is returned to the sender. Additionally, because block list providers usually contain different offender categories, you can specify the matches you want to reject. Most block list providers do screening for three types of offenders:

  • Sources of unsolicited commercial e-mail. These lists are generated from scanning unsolicited commercial e-mails and adding the source address to the list.

  • Known open relay servers. These lists are calculated by identifying open relay SMTP servers on the Internet. The most common reason for an open relay server is misconfiguration by the system administrator.

  • Dial-up user lists. These lists are created from either existing Internet service provider (ISP) lists that contain IP addresses with dial-up access, or from inspection of addresses that indicate a probable dial-up connection.

How Block List Providers Match Offending IP Addresses

After you set up your connection filter, when an e-mail message is sent to your organization, Exchange contacts the block list provider. The provider checks for the existence of an A (host) record in its DNS. Exchange queries for this information in a specific format. For example, if the connecting address is 192.168.5.1, and the block list provider's organization is contoso.org, then Exchange queries for the existence of the following record:

<reverse IP address of the connecting server>.<dns name for the block list organization> IN A 127. 0.0.x

which, in this case, is:

1.5.168.192..contoso.org

If this IP address is found on the provider's list, the provider returns a 127.0.0.x status code that indicates an offending IP address and the type of offense. All block list providers return a response code of 127.0.0.x, where x indicates the type of offense. This number varies, depending on the block list provider.

Understanding Block List Provider Response Codes

As mentioned earlier, if a block list provider finds a match, the provider always returns a status code of 127.0.0.x. The status code is either an explicit return code or a bit mask, which is multi-functional return. If your block list provider returns a value, you can specify which values you want to filter against. However, if your block list provider returns a bit mask, you must understand how a bit mask works to specify the matches you want to filter.

A bit mask is a method used for verifying that a particular bit is set for an entry. A bit mask differs from a traditional mask in that it checks for a specific bit value, as opposed to a subnet mask, which checks for a range of values. Consider the following example.

For each match in its block list, assume a block list provider returns the status codes listed in the following table.

Block list status code examples

Category Returned status code

Known source of unsolicited e-mail

127.0.0.3

Dial-up user account

127.0.0.2

Known relay server

127.0.0.4

However, if an IP address is a member of two lists, the block list provider adds the values of the last octet. Therefore, if an IP address is on the list of known relay servers and known sources of unsolicited e-mails, the block list provider returns a status code of 127.0.7, where 7 is the combined values of the last octet returned for known sources of unsolicited commercial e-mail and known relay servers.

To filter against only known sources of unsolicited commercial e-mail, enter a bit mask value of 0.0.0.3; the block list then filters against any of the possible values, in this case, 127.0.0.3, 127.0.0.5, and 127.0.0.7, and 127.0.0.9.

The following table lists the bit mask values associated with each of the example status codes.

Block list status code and corresponding bit mask examples

Category Returned status code Bit mask

Known source of unsolicited e-mail

127.0.0.3

0.0.0.3

Dial-up user account

127.0.0.2

0.0.0.2

Known relay server

127.0.0.4

0.0.0.4

Known relay server and dial-up user account

127.0.0.6

0.0.0.6

For the Known relay server and dial-up user account category, the bit mask 0.0.0.6 returns a match for an IP address only if it appears on both the known relay server and dial-up user account lists. It does not return a match if the IP address appears on only one of the two lists. You cannot use a bit mask to check for a single match in multiple lists.

Note

A bit mask checks only against a single value. If you set a bit mask value that is returned when an IP address appears on two lists, the mask will match only IP addresses that appear on both lists. If you want to check for an IP address on either of two lists, enter the status codes for these settings.

Specifying Exceptions to the Connection Filter Rule

You can allow message delivery to specific recipients, regardless of whether they appear on a block list. This is useful if you want to allow legitimate organizations to communicate with your administrators by contacting the postmaster account. For example, if a legitimate company has a server inadvertently configured to allow open relaying, e-mail messages from this company to your users would be blocked. However, if you configured connection filtering to allow message delivery to the postmaster account in your organization, then the administrator in the blocked company could send mail your postmaster account to communicate their situation or inquire as to why their mail was rejected.

Enabling Connection Filtering

To enable connection filtering, perform the following steps:

  1. Create the connection filter using the Connection Filtering tab on the Message Delivery Properties dialog box.

  2. Apply the filter at the SMTP virtual server level.

  3. New in SP2: Specify the servers in your internal network that you want to be excluded from connection filtering.

Each of these steps is detailed in the following sections.

Step 1: Configuring Connection Filtering

To configure connection filtering, perform the following tasks:

  • Create global accept and deny lists

  • Create connection filtering rules

  • Create exceptions to the connection filtering rules.

Creating Global Accept and Deny Lists

Connection filtering allows you to create global accept and deny lists. You can use these lists to always accept or always reject mail sent from specific IP addresses, regardless of whether or not you use a block list service provider. Any IP address that appears on the global accept list is automatically accepted, and any connection filtering rules are bypassed. Similarly, any IP address that appears on the global deny list is automatically rejected.

Entries in the global accept list take precedence over the entries in the global deny list. Exchange checks the global accept list before the global deny list; so, if you wanted to reject connections from a specific subnet and mask, but accept connections from a single IP address within this range, you would:

  • Enter the IP address from which you want to accept connections on the global accept list.

  • Enter the subnet and mask for the range of IP addresses from which you want to reject connections on the global deny list.

When the connecting IP address you added to the global accept list attempts to connect to your Exchange server, Exchange checks the global accept list first. Because Exchange finds a match for this IP address, the connection is accepted, and Exchange performs no additional connection filtering checks.

For detailed instructions, see "How to Create a Global Accept List" and "How to Create a Global Deny List" in the Exchange Server 2003 Transport and Routing Guide.

Creating a Connection Filtering Rule

For detailed instructions about creating a connection filter rule, see "How to Create a Connection Filter" in the Exchange Server 2003 Transport and Routing Guide.

You can create exceptions to the connection filter rule. Specifically, you can allow message delivery to specific recipients (for example, to the postmaster), regardless of whether the connecting IP address is on a block list.

For detailed instructions, see "How to Specify an Exception to a Connection Rule" in the Exchange Server 2003 Transport and Routing Guide.

Step 2: Applying the Connection Filter to the Appropriate SMTP Virtual Servers

After creating the connection filter, you must apply it to the appropriate SMTP virtual servers. Usually, you apply the connection filter on the SMTP virtual servers that exist on your gateway servers that accept inbound Internet e-mail. Use the following procedure to apply a connection filter to an SMTP virtual server.

For detailed instructions, see "How to Apply a Connection Filter to An SMTP Virtual Server" in the Exchange Server 2003 Transport and Routing Guide.

New in SP2: Step 3: Specifying the Servers to Exclude from Connection Filtering

In Exchange Server 2003 SP2, you can enable connection filtering behind the perimeter of your network. To do this, on the General tab of the Message Delivery Properties dialog box, you specify the IP address of the servers in your internal network that you want to exclude from IP address validation.

You can specify individual IP addresses or groups of IP addresses. You must include all servers in your organization that process incoming SMTP mail. You must also include all servers that route mail to the Sender ID and connection filtering deployment servers. If any of the servers that process SMTP mail are located on the perimeter, you should include all perimeter IP addresses of these servers.

If an IP address on the e-mail message received by the Sender ID or connection filtering deployment server is found on this list, Exchange Server will skip the IP address without running Sender ID and connection filtering validation on it. You can add up to 196 IP addresses to the list.

For information about how to specify the server in your internal network, see "Specify IP Address Configuration Data for Connection Filtering" in the Exchange Server 2003 SP2 online Help.

Inbound Recipient Filtering

With recipient filtering, you can block mail that is destined to all invalid recipients. You can also block mail to any recipients who are specified in a recipient filter list, whether they are valid or invalid.

The recipient filter blocks mail destined to invalid recipients by filtering inbound mail (based on Active Directory lookups) for each intended recipient. You can filter mail based on the following criteria:

  • If the recipient does not exist in Active Directory

  • If the sender does not have the appropriate permissions.

Any incoming mail matching these criteria is rejected, and the SMTP virtual server returns a 550 5.x.x error during the SMTP session.

Note

Exchange only performs Active Directory lookups and blocks invalid recipients for incoming mail destined to a domain for which it is authoritative. This setting is configured in recipient policies.

You can also configure recipient filtering to filter messages sent to specified e-mail address (valid or invalid) within your organization If a message is sent to any of the specified recipients, Exchange returns a 5.x.x level error during the SMTP session.

By default, Exchange accepts mail that is destined for any recipient (invalid or valid) and then sends non-delivery reports (NDRs) for all invalid recipients. Additionally, because unsolicited mail is typically sent from invalid addresses, Exchange attempts to re-deliver NDRs to non-existent senders, thereby expending more resources. If you enable recipient filtering, Exchange no longer expends resources in this manner because invalid recipients are filtered. However, enabling recipient filtering to resolve recipients in Active Directory can potentially allow malicious senders to resolve valid e-mail addresses; this is because SMTP sessions issue different responses for valid and invalid recipients.

Note

Recipient filter rules apply only to anonymous connections. Authenticated users and Exchange servers bypass these validations.

Enabling Recipient Filtering

To enable recipient filtering, perform the following steps:

  1. Create the recipient filter using the Recipient Filtering tab in the Message Delivery Properties dialog box.

  2. Apply the filter at the SMTP virtual server level.

Each of these steps is detailed in the following sections.

Step 1: Creating a recipient filter

First, you need to create a recipient filter. For detailed instructions, see "How to Create a Recipient Filter" in the Exchange Server 2003 Transport and Routing Guide.

Step 2: Applying the Recipient Filter to the Appropriate SMTP Virtual Servers

After creating the recipient filter, you must apply it to the appropriate SMTP virtual servers. Usually, you apply the recipient filter on the SMTP virtual servers that exist on your gateway servers that accept inbound Internet e-mail. Use the following procedure to apply a recipient filter to an SMTP virtual server.

For detailed instructions, see "How to Apply a Recipient Filter to an SMTP Virtual Server" in the Exchange Server 2003 Transport and Routing Guide.

New in SP2: Sender ID Filtering

In Exchange Server 2003 SP2, you can use Sender ID filtering. Sender ID is an e-mail industry initiative that you can use to provide greater protection against unsolicited commercial e-mail (UCE) and phishing schemes. Specifically, the Sender ID framework is a protocol created to help reduce e-mail domain spoofing and to provide greater protection against phishing schemes by verifying an e-mail message's sender. For more information about Sender ID, see the Sender ID Web site.

Configuring Sender ID

The following overview discusses the three steps you must follow to configure Sender ID filtering in Exchange Server 2003 SP2.

  1. Specify how the server should handle messages that failed Sender ID validation by selecting one of the following options on the Sender ID Filtering tab of the Message Delivery Properties dialog box.

    • Select Accept (the Sender ID status will be attached to the message for further anti-spam processing) if you want the Sender ID filter to stamp the validation results to the message and be processed by further anti-spam processing, such as intelligent message filter. This is the default option.

    • Select Delete (the message will be accepted and then deleted; no NDR will be sent back to the sender) if you want the Sender ID filter to accept the mail and then delete it without sending the non-delivery report (NDR) to the user.

    • Select Reject (the message will not be accepted; the sending party will be responsible for NDR generation) if you want the Sender ID filter to reject the mail on the SMTP protocol level and issue an NDR message to the user. Specifically, the sending server is responsible for generating an NDR.

  2. Specify the IP addresses of the servers in your internal network that you want to be excluded from IP address validation on the General tab of the Message Delivery Properties dialog box. You can specify individual IP addresses or groups of IP addresses. You must include all servers in your Exchange organization that process incoming SMTP mail. You must also include all servers that route mail to the Sender ID and connection filtering deployment servers. If any of the servers that process SMTP mail are located on the perimeter, you should include all perimeter IP addresses of these servers. If an IP address on the e-mail message received by the Sender ID or connection filtering deployment server is found on this list, Exchange Server will skip the IP address without running Sender ID and connection filtering validation on it. You can add up to 196 IP addresses to list.

  3. Enable Sender ID on the SMTP virtual servers. After configuring Sender ID filtering options, you must enable Sender ID filtering on the SMTP virtual servers in your Exchange organization.

    For detailed information about how to perform each of these tasks, see "Configure Sender ID Filtering" in the Exchange Server 2003 SP2 online Help.

New in SP2: Intelligent Message Filtering

In Exchange Server 2003 SP2, intelligent message filtering is installed and ready to use when you install Exchange Server 2003 SP2.

Note

If the Exchange Server 2003 installation program detects that you are running Intelligent Message Filter, it will prompt you to uninstall it before proceeding with the Exchange Server 2003 SP2 installation.

Intelligent message filtering allows you to block unsolicited commercial e-mail (UCE), also known as spam, on your gateway SMTP virtual servers. Gateway SMTP virtual servers are SMTP virtual servers that accept incoming Internet e-mail.

For more information about intelligent message filtering, see the Exchange Intelligent Message Filter Web site.

Configuring Intelligent Message Filtering

The following overview discusses the steps you must follow to configure Sender ID filtering in Exchange Server 2003 SP2.

  1. Create an Intelligent Message Filter using the options on the Intelligent Message Filtering tab of the Message Delivery Properties dialog box. You can set two thresholds that determine how Intelligent Message Filter handles e-mail messages with various SCL ratings: a gateway threshold with an associated action to take on messages above this threshold, and a mailbox store threshold.

    • If a message has a SCL rating higher than the gateway threshold, Intelligent Message Filter takes the action you have specified. These options include Archive, Delete, No Action, and Reject.

    • If the message has a SCL rating below the gateway threshold, the message is sent to the Exchange mailbox store of the recipient. At the Exchange mailbox store, if the message has a higher SCL rating than the mailbox store threshold, the mailbox store delivers the message to the user's Junk E-mail folder rather than to the Inbox.

  2. Enable Intelligent Message Filter on the SMTP virtual servers. After configuring Intelligent Message Filter options, you must enable Intelligent Message Filter on the SMTP virtual servers in your Exchange organization.

For detailed information about how to perform each of these tasks, see "Configure Intelligent Message Filtering" in the Exchange Server 2003 SP2 online Help.

Updated in SP2: Understanding How Enabled Filters Are Applied

Exchange Server 2003 supports the following filters:

  • IP restrictions on a virtual server basis

  • Connection filtering

  • Recipient filtering

  • Sender filtering

  • Sender ID filtering

  • Intelligent message filtering

Although connection filtering, recipient filtering, sender filtering, Sender ID filtering, and intelligent message filtering are all configured in Message Delivery Properties, they must be enabled on individual SMTP virtual servers. In contrast, IP restrictions are configured directly on each SMTP virtual server.

This section shows the order in which these filters, when configured and enabled, are checked during an SMTP session. Filtering and IP restrictions are checked in the following manner.

Note

This section has been updated to provide information about the anti-spam process on servers running Exchange Server 2003 SP2. For the purposes of this example, it is assumed that Exchange Server 2003 SP2 is installed on a gateway computer.

  1. An SMTP client attempts to connect to the SMTP virtual server.

  2. The IP address of the connecting client is checked against the SMTP virtual server's IP restrictions (configured on the Access tab of the SMTP virtual server Properties):

    • If the connecting IP address is on the list of restricted IPs, the connection is immediately dropped.

    • If the connecting IP address is not on the list of restricted IPs, the connection is accepted.

  3. The SMTP client issues an EHLO or HELO command.

  4. The SMTP client issues a MAIL FROM: command, similar to the following:

    MAIL FROM: dylanm@contoso.com

  5. The IP address of the SMTP client is then checked against the global accept list (configured in Exchange System Manager on the Connection Filtering tab in the Message Delivery Properties dialog box).

    • If the connecting IP address is on the global accept list, the global deny list is not checked. Proceed to Step 7.

    • If the connecting IP address is not on the list global accept list, Steps 6 and 7 are performed.

  6. The IP address of the SMTP client is checked against the global deny list (configured in Exchange System Manager on the Connection Filtering tab in the Message Delivery Properties dialog box).

    • If the IP address of the SMTP client is on the global deny list, the connection is dropped.

    • If the IP address of the SMTP client is not on the global deny list, the session continues.

  7. Sender filtering checks the sender specified in the MAIL FROM command against its list of blocked senders (configured in Exchange System Manager on the Sender Filtering tab in the Message Delivery Properties dialog box).

    • If the sender appears on the blocked senders list, one of two things happen, depending on how sender filtering is configured:

      - If sender filtering is configured to drop the connection, the connection is dropped.

      - If sending filtering is configured to accept messages without notifying the sender, the session continues; however, mail is sent to the Badmail directory and not delivered to the intended recipient.

    • If the sender does not appear on the sender-filtering list, the SMTP virtual server issues a response similar to the following.

      250 2.1.0 dylanm@contoso.com...Sender OK

  8. The connecting SMTP server issues a RCPT TO command similar to the following:

    RCPT TO: kim@example.com

  9. The connection filtering rules check the connecting IP address against any block lists provided by their block list service providers.

    • If the IP address of the SMTP client is in the accept list, the connection filter rules are bypassed. Proceed to Step 10.

    • If the IP address of the SMTP client is on a block list service provider's block list, the SMTP virtual server returns an error code and then sends the customized error message configured for the connection filtering rule.

    • If the IP address of the SMTP client is not on a block list service provider's block list, the session continues.

  10. Connection filtering checks to see if the intended recipient is on the connection filtering exception list.

    • If the recipient is on this list, the communication is accepted, and no other checks are applied at the RCPT TO command. Proceed to Step 13.

    • If the recipient does not appear on the exception list, the recipient is checked against other filters.

  11. If the recipient does not appear on the exception list configured in connection filtering, the recipient is then checked against any blocked recipients configured in recipient filtering.

    • If the recipient is a blocked recipient, the SMTP virtual server returns an invalid recipient error.

    • If the recipient is not a blocked recipient, the session continues.

  12. If the recipient is not a blocked recipient, then Active Directory is checked to ensure that the intended recipient exists in Active Directory.

    • If the intended recipient is not a valid recipient that exists in Active Directory, the SMTP virtual server returns an invalid recipient error.

    • If the recipient is a valid recipient that exists in Active Directory, the session continues.

  13. For each additional recipient specified in a RCPT TO command, Steps 10 through 12 are applied.

  14. The connecting server then issues a DATA command similar to the following

    DATA

    To: Kim Akers

    From: dylanm@contoso.com<Dylan Miller>

    Subject: Mail Message

  15. Sender filtering then checks that the From address does not match a blocked sender.

    • If the sender specified in the DATA command is a blocked sender, one of two things happen:

      - If sender filtering is configured to drop the connection, then the SMTP virtual server returns a 5.1.0 "Sender Denied" error and drops the connection.

      - If sending filtering is configured to accept messages without notifying the sender, the session continues; however, mail is sent to the Badmail directory and not delivered to the intended recipient.

    • If the sender specified in the DATA command is not a blocked sender, the message is accepted and queued for delivery.

  16. Messages are processed by Sender ID validation.

  17. Messages are processed by intelligent message filtering.

Improved Ability to Restrict Submissions to an SMTP Virtual Server

In Exchange Server 2003, you can restrict submissions to an SMTP virtual server to a limited number of security principles though the standard Windows 2000 Server or Windows Server 2003 Discretionary Access Control List (DACL). This allows you to specify groups of users who can submit mail to a virtual server.

Note

Do not restrict submissions on SMTP virtual servers that accept Internet mail.

For detailed instructions, see "How to Restrict Submissions to an SMTP Server Based on a Security Group" in the Exchange Server 2003 Transport and Routing Guide.

Improved Ability to Restrict Relaying on an SMTP Virtual Server

In Exchange 2003, you can restrict relaying to a limited number of security principles though the standard Windows 2000 Discretionary Access Control List (DACL). This allows you to specify groups of users who can relay through a virtual server.

Restricting relaying on virtual servers is useful if you want to allow a group of users to relay mail to the Internet, but deny relay privileges for a different group.

For detailed instructions, see "How to Restrict Relaying Based on a Security Group" in the Exchange Server 2003 Transport and Routing Guide.