When you create a connection-filtering rule, SMTP uses the rule to perform a DNS lookup to a list that is provided by a third-party block list service. The connection filter matches each incoming IP address against the IP addresses on 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 value can vary, 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 that you want to reject. Most block list providers screen for three types of offenders:

• Sources of spam   These lists are generated by scanning unsolicited commercial e-mail messages and adding the source address to the list.
  
• Known open relay servers   These lists are created by identifying open relay SMTP servers on the Internet. The most common reason for an open relay server is a configuration mistake 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 the inspection of addresses that indicate a probable dial-up connection.
  

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, 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. The x value varies, depending on the block list provider.

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 a multifunctional return code. 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 that you want to filter.

A bit mask is a method that is 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 that are listed in the following table.

Examples of block list status codes

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 spam, the block list provider returns a status code of 127.0.0.7, where 7 is the combined values of the last octet that is returned for the known sources of unsolicited commercial e-mail status code and the known relay servers status code.

If you want 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, 127.0.0.7, and 127.0.0.9.

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

Examples of block list status codes and corresponding bit mask values

In the last category in this table ("Known relay server and dial-up user account"), 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 matches 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.

You can allow message delivery to specific recipients, regardless of whether they appear on a block list. This exception 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 configure connection filtering to allow message delivery to the postmaster account in your organization, the administrator in the blocked company could send mail to your postmaster account to communicate their situation or inquire as to why their mail was rejected.

To enable connection filtering, perform the following steps:

1. Create the connection filter by using the Connection Filtering tab on the Message Delivery Properties dialog box. For detailed instructions, see How to Create a Recipient Filter.
   
2. Apply the filter at the SMTP virtual server level. For detailed instructions, see How to Apply a Recipient Filter to an SMTP Virtual Server.
   

Each of these steps is detailed in the following sections.

 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.
  

For detailed instructions about creating global accept lists and global deny lists, see the following topics:

• How to Create a Global Accept List
  
• How to Create a Global Deny List
  

For detailed instructions on creating exceptions to the connection filtering rules, see the following topic:

• How to Create a Connection Filter
  
• How to Specify an Exception to a Connection Rule
  

 Applying the Connection Filter to the Appropriate SMTP Virtual Servers

After creating the connection filter and any exceptions for the filter, you must apply it to the appropriate SMTP virtual servers. Usually, you apply the connection filter to the SMTP virtual servers that exist on your gateway servers that accept inbound Internet e-mail messages. 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.

Sender filtering functions in the same way in Exchange Server 2003 as it did in Exchange 2000 Server; it allows you to filter messages that are sent by a specific sender. You can block messages that are sent by any users in a domain or by a specific sender.

 Enabling Sender Filtering

To enable sender filtering, perform the following steps:

1. Create the sender filter by using the Sender Filtering tab in the Message Delivery Properties dialog box in Global Settings.
   
2. Apply the filter at the SMTP virtual server level.
   

Exchange 2003 supports the following filters and IP restrictions:

• Connection filtering
  
• Recipient filtering
  
• Sender filtering
  
• IP restrictions on a virtual server basis
  

Although connection filtering, recipient filtering, and sender 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 IP restrictions and filters, when configured and enabled, are checked during an SMTP session.

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 Connection button 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: ted@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. The process skips Step 6 and proceeds to Step 7.
     
   • If the connecting IP address is not on the 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 that is 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 actions occur, depending on how sender filtering is configured:
     - If sender filtering is configured to drop the connection, the connection is dropped.
     - If sender 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 ted@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 that are 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. The process proceeds to Step 10.
     
   • Connection filtering checks each service provider's block list in the order that is configured in connection filtering. If connection filtering finds a match on a provider's block list, the SMTP virtual server returns an error code and then sends the customized error message that is configured for the connection filtering rule. After a match is found, no other service provider lists are checked.
     
   • 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 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. The process skips Steps 11 and 12 and proceeds 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 that is configured in connection filtering, the recipient is then checked against any blocked recipients that are 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, 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 that is specified in a RCPT TO command, Steps 10 through 12 are applied.
    
14. The connecting server then issues a DATA command that is similar to the following:
    DATA
    To: Kim Akers
    From: ted@contoso.com<Ted Bremer>
    Subject: Mail Message
    
15. Sender filtering then checks that the From address does not match a blocked sender.
    
    • If the sender that is specified in the DATA command is a blocked sender, one of two actions occur:
      - If sender filtering is configured to drop the connection, the SMTP virtual server returns a 5.1.0 Sender Denied error and drops the connection.
      - If sender 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 that is specified in the DATA command is not a blocked sender, the message is accepted and queued for delivery.
      

You can educate your users on how to identify spoofed mail. Unlike Exchange 2000, Exchange 2003 does not resolve anonymous e-mail messages to their display names in its default configuration. Therefore, when mail is sent from a forged address, Exchange 2003 does not resolve the sender's e-mail address to its display name in the global address list.

To understand how Exchange 2003 prevents spoofing, suppose that you have an internal user named Ted Bremer, and he sends mail internally from your domain example.com. The e-mail message shows his sending address as Ted Bremer, which is the display name that is configured in Active Directory for ted@example.com. (This is because when Ted Bremer sends mail, he is an authenticated user.) Exchange then verifies that Ted Bremer has "send as" permissions under his credentials and then resolves his e-mail address to his display name in Active Directory. Spoofing occurs when an unauthorized user pretends to be Ted by forging this address and then sends mail to another user in your domain.

Exchange 2003 does not resolve e-mail addresses that originate externally. Therefore, when an anonymous user attempts to send mail spoofing Ted's identity, Exchange will not resolve the sending address in the From line to its display name. Instead, ted@example.com will appear in the From line of the e-mail. If your users understand this difference, they can at least identify spoofed mail.

However, Exchange 2000 servers do resolve anonymous e-mail by default. If your organization contains Exchange 2000 servers, and they resolve an anonymous e-mail message and send it to an Exchange 2003 server, the address resolves to its display name in the GAL. To prevent this, configure your Exchange 2000 servers so that they do not resolve anonymous mail.

For detailed instructions, see How to Verify That Exchange 2003 is Configured to Not Resolve Anonymous Mail and How to Configure Exchange 2000 to Not Resolve External Email Addresses.