Export (0) Print
Expand All

Configuring Connection Filtering

 

Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Topic Last Modified: 2007-07-06

This topic provides an overview of how to configure connection filtering. For customized or more advanced configuration, see the links in each section of this topic. For more information about how connection filtering works, see Connection Filtering.

noteNote:
From the perspective of configurable components on a computer that has the Edge Transport server role installed, the connection filtering feature refers to a collection of IP Block lists, IP Allow lists, IP Block List providers, and IP Allow List providers. Connection filtering is used to extend the server.

When you configure connection filtering, you must follow these steps:

  1. Enable connection filtering components.

  2. Add IP addresses to the IP Allow lists and IP Block lists.

  3. Configure IP Allow List providers and IP Block List providers.

  4. Configure connection filtering for Edge Transport servers that are not the first Simple Mail Transfer Protocol (SMTP) entry point.

  5. Test IP Block and IP Allow functionality.

importantImportant:
Configuration changes that you make to connection filtering by using the Exchange Management Console or the Exchange Management Shell are made only to the local computer that has the Edge Transport server role installed. If you have multiple instances of the Edge Transport server role running in your organization, you must apply connection filtering configuration changes to each computer.

By default, connection filtering is enabled on the Edge Transport server for inbound messages that come from the Internet but are not authenticated. These messages are handled as external messages. You can disable the filter in individual computer configurations by using the Exchange Management Console or the Exchange Management Shell.

When connection filtering is enabled on a computer, the Connection Filter agent filters all messages that come through all Receive connectors on that computer. As noted earlier in this topic, only messages that come from external sources are filtered. External sources are defined as non-authenticated sources. These are considered anonymous Internet sources.

For more information about how to configure Receive connectors and how message source categories are determined, see Receive Connectors.

As a best practice, you should not filter messages from trusted partners or from inside your organization. When you run anti-spam filters, there is always a chance that the filters will detect false positives. To reduce the chance of mishandling legitimate e-mail messages, you should enable anti-spam agents to run only on messages from potentially untrusted and unknown sources. You can enable and disable connection filtering on messages from any source by using the Exchange Management Shell.

For more information about how to enable connection filtering, see How to Enable Connection Filtering.

As explained in Connection Filtering, IP Block lists and IP Allow lists are administrator-defined lists that specify IP addresses and IP address ranges that are acted on by connection filtering. If an originating IP address matches an IP address or IP address range on the IP Block list, the Connection Filter agent processes all RCPT TO: headers in the message and then denies the message after the MAIL FROM command. When an originating IP address matches an IP address or IP address range on the IP Allow list, the Connection Filter agent sends the message to the destination without additional processing by other anti-spam agents. For more information about how the anti-spam agents work together and the order in which they are applied, see Anti-Spam and Antivirus Functionality.

noteNote:
The use of Internet Protocol Version 6 (IPv6) addresses and IP address ranges is supported only when Microsoft Exchange Server 2007 Service Pack 1 (SP1) is deployed on a computer that is running Windows Server 2008, both IPv6 and Internet Protocol Version 4 (IPv4) are enabled on that computer, and the network supports both IP address versions. If Exchange 2007 SP1 is deployed in this configuration, all server roles can send data to and receive data from devices, servers, and clients that use IPv6 addresses. A default installation of Windows Server 2008 enables support for IPv4 and IPv6. If Exchange 2007 SP1 is installed on Windows Server 2003, IPv6 addresses are not supported. For more information about Exchange 2007 SP1 support for IPv6 addresses, see IPv6 Support in Exchange 2007 SP1 and SP2.

For more information about how to add IP addresses to the IP Block list and IP Allow list, see How to Add IP Addresses to the IP Allow List and IP Block List.

IP Block list and IP Allow list provider services can help you reduce spam and increase overall message processing on your Edge Transport server. You should consider configuring multiple IP Block List provider services and IP Allow List provider services.

noteNote:
Multiple IP Block List provider services are sometimes referred to as real-time block list (RBL) services. IP Allow List provider services are sometimes referred to as safe list services.

For each IP Block List provider service that you configure, you can customize the SMTP 550 error that is returned to the sender when the sender IP address is matched to an IP Block List provider service and is subsequently blocked by the Connection Filter agent. It is a best practice to customize the SMTP 550 error to identify the IP Block List provider service that identifies the sender as a blocked IP address. This best practice enables legitimate senders to contact the IP Block List provider service so that they can be removed from the IP Block List provider service's IP Block list.

Different IP Block List provider services may return different codes when the IP address of a remote server that is sending a message matches an IP address on an IP Block List provider service's IP Block list. Most IP Block List provider services return one of the following data types: bitmask or absolute value. Within these data types, there may be multiple values that indicate the type of list that the submitted IP address is on.

This section shows an example of the status codes returned by most Block List providers. See the documentation from the specific provider on the status codes that the provider returns.

For bitmask data types, the IP Block List provider service returns a status code of 127.0.0.x, where the integer x is any one of the values that are listed in the following table.

Values and status codes for bitmask data types

Value Status Code

1

The IP address is on an IP Block list.

2

The SMTP server is configured to act as an open relay.

4

The IP address supports a dial-up IP address.

For absolute value types, the IP Block List provider service returns explicit responses based on the cause of the block of the IP address. The following table shows some examples of absolute values and the explicit responses.

Values and status codes for absolute value data types

Value Explicit Response

127.0.0.2

The IP address is a direct spam source.

127.0.0.4

The IP address is a bulk mailer.

127.0.0.5

The remote server that is sending the message is known to support multistage open relays.

For more information about how to configure IP Allow List providers and IP Block List providers, see How to Configure IP Allow List and IP Block List Providers.

In some organizations, the Edge Transport server role is installed on computers that do not process SMTP requests directly on the Internet. In this scenario, the Edge Transport server is behind another front-end SMTP server that processes inbound messages directly from the Internet. In this scenario, the Connection Filter agent must be able to extract the correct originating IP address from the message. To extract and evaluate the originating IP address, the Connection Filter agent must parse the Received headers from the message and compare those headers to the known SMTP server in the perimeter network.

When an RFC-compliant SMTP server receives a message, the server updates the message's Received header with the domain name and IP address of the sender. Therefore, for each SMTP server that is between the originating sender and the Edge Transport server, the SMTP server adds an additional Received header entry.

When you configure your perimeter network to support Microsoft Exchange Server 2007, you must specify all the IP addresses for the SMTP servers in your perimeter network. The IP address data is replicated to Edge Transport servers by EdgeSync. When messages are received by the computer that runs the Connection Filter agent, the IP address in the Received header that does not match an SMTP server IP address in your perimeter network is assumed to be the originating IP address.

You must specify all internal SMTP servers on the transport configuration object in the Active Directory forest before you run connection filtering. Specify the internal SMTP servers by using the InternalSMTPServers parameter on the Set-TransportConfig cmdlet.

After you configure an IP Block List provider service or IP Allow List provider service, you can test to make sure that connection filtering is configured correctly for the particular service. Most IP Block List provider services or IP Allow List provider services provide test IP addresses that you can use to test their services. When you run a test against an IP Block List provider service or an IP Allow List provider service, the Connection Filter agent issues a Domain Name System (DNS) query that is based on the real-time block list (RBL) IP address that should respond with a specific response. For more information about RBL services, see Connection Filtering. For more information about how to test IP addresses against an IP Block List provider service or an IP Allow List provider service, see Test-IPAllowListProvider and Test-IPBlockListProvider.

 
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft