Connection filtering on Edge Transport servers in Exchange Server
Connection filtering is an antispam feature in Exchange Server that allows or blocks email based on the message source. Connection filtering is performed by the Connection Filtering agent that's available only on Edge Transport servers, and is basically unchanged from Exchange Server 2010. The Connection Filtering agent relies on the IP address of the connecting mail server to determine what action, if any, to take on an inbound message.
By default, the Connection Filtering agent is the first antispam agent to evaluate an inbound message on an Edge Transport server. The source IP address of the SMTP connection is checked against the allowed and blocked IP addresses. If the source IP address is specifically allowed, the message is sent to the recipients in your organization without additional processing by other antispam agents. If the source IP address is specifically blocked, the SMTP connection is dropped. If the source IP address isn't specifically allowed or blocked, the message flows through the other antispam agents on the Edge Transport server.
Connection filtering compares the IP address of the source mail server to the values in the IP allowlist, the IP blocklist, IP allowlist providers, and IP blocklist providers. You need to configure at least one of these four IP address data stores for connection filtering to function. If you don't specify any IP address data, you should disable the Connection Filtering agent. For more information, see Connection filtering procedures on Edge Transport servers.
IP blocklist
The IP blocklist contains the IP addresses of email servers that you want to block. You manually maintain the IP addresses in the IP blocklist. You can add individual IP addresses or IP address ranges. You can specify an expiration time that specifies how long the IP address entry will be blocked. When the expiration time is reached, the IP address entry in the IP blocklist is disabled.
If the Connection Filtering agent finds the source IP address on the IP blocklist, the SMTP connection will be dropped after all the RCPT TO headers (envelope recipients) in the message are processed.
IP addresses can also be automatically added to the IP blocklist by the Sender Reputation feature of the Protocol Analysis agent. For more information, see Sender reputation and the Protocol Analysis agent.
IP allowlist
The IP allowlist contains the IP addresses of email servers that you want to designate as trustworthy sources of email. Email from mail servers that you specify in the IP allowlist is exempt from processing by other Exchange antispam agents.
You manually maintain the IP addresses in the IP allowlist. You can add individual IP addresses or IP address ranges. You can specify an expiration time that specifies how long the IP address entry will be allowed. When the expiration time is reached, the entry in the IP allowlist is disabled.
IP blocklist providers
IP blocklist providers are frequently referred to as real-time blocklists, or RBLs. IP blocklist providers compile lists of mail server IP addresses that send spam. Many IP blocklist providers also compile lists of mail server IP addresses that could be used for spam. Examples include mail servers that are configured for open relay, Internet service providers (ISPs) that assign dynamic IP addresses, and ISPs that allow SMTP mail server traffic from dial-up accounts.
When you configure connection filtering to use an IP blocklist provider, the Connection Filtering agent compares the IP address of the connecting mail server to the list of IP addresses at the IP blocklist provider. If there's a match, the message isn't allowed in your organization. You can configure connection filtering to use multiple IP blocklist providers, and you assign different priority values to each provider.
The Connection Filtering agent checks the source IP address at the IP allowlist and the IP blocklist. If the IP address doesn't exist on either list, the Connection Filtering agent queries the IP blocklist provider according to the priority value that you assigned. If the IP address is defined at an IP blocklist provider, the Edge Transport server waits for and processes the RCPT TO header, responds to the sending mail server with an SMTP 550 error, and closes the connection. The connection isn't immediately dropped so that the connection attempt can be logged, and because you can specify recipients that are exempt from having messages blocked by any IP blocklist providers.
If the IP address isn't defined at any of the IP blocklist providers, the Content Filtering agent hands the message off to the next transport agent on the Edge Transport server.
For each IP blocklist provider, you can customize the SMTP 550 error that's returned to the sender when a message is blocked. You should identify the IP blocklist provider that identified the message source as spam. If a legitimate source mail server is erroneously identified as a spam source, the administrator can then contact the IP blocklistt provider and take the steps necessary to remove the mail server from the IP blocklist provider.
IP blocklist providers can return different codes to identify why an IP address is defined in their lists. Most IP blocklist providers return bitmask or absolute value data types. Within these data types, the IP blocklist provider can use multiple values to classify the IP address by threat type.
There are issues to consider when using IP blocklist providers:
Outages or delays at the IP blocklist provider service can cause delays in the processing of messages on the Edge Transport server. You should always select reliable IP blocklist providers.
Source servers that you know to be legitimate can be erroneously identified as spam sources. For example, the mail server can be unintentionally configured to act as an open relay. You should always select IP blocklist providers that provide clear procedures for evaluation and removal from their services.
Bitmask and absolute value examples
This section shows an example of the status codes returned by most blocklist providers. For details about the status codes that the provider returns, see the documentation from the specific provider.
For bitmask data types, the IP blocklist provider service returns a status code of 127.0.0. x, where the integer x is any one of the values listed in the following table.
Values and status codes for bitmask data types
| Value | Status code |
|---|---|
| 1 | The IP address is on an IP blocklist. |
| 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 blocklist provider returns explicit responses that define why the IP address is defined in their blocklist. The following table shows 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 sending the message is known to support multistage open relays. |
IP allowlist providers
IP Allowlist providers are also known as safe lists. IP allowlist providers are configured just like IP blocklist providers, but the results are the opposite: they define mail server IP addresses that are definitely not associated with spam activity. If the IP address of the connecting mail server is defined at an IP allowlis provider, the message is exempt from processing by other Exchange antispam agents. For this reason, IP blocklist providers are used much more frequently than IP allowlis providers. Choose your IP allowlis providers carefully.
Test IP blocklist providers and IP allowlis providers
After you configure connection filtering to use an IP blocklist provider or an IP allowlist provider, you can run tests to verify that the providers are working correctly. Most providers provide test IP addresses that you can use to test their services. When you test a provider, the Connection Filtering agent issues a DNS query that should result in a specific response from the provider. For more information about how to test IP addresses against an IP blocklist provider service or an IP allowlis provider service, see Connection filtering procedures on Edge Transport servers.
Configure connection filtering on Edge Transport servers that aren't directly connected to the Internet
You can use connection filtering on Edge Transport servers that don't directly receive email from the Internet. In this scenario, the Edge Transport server is behind another mail server that receives and processes messages directly from the Internet. For example, your organization might send email traffic through an antispam server, service, or appliance before the messages reach the Edge Transport server. In this scenario, the Connection Filtering agent needs to extract the correct source IP address from the message. To do this, the Connection Filtering agent needs to parse the Received header field values in the message header and compare those values to the known IP addresses of the mail server that sits between the Edge Transport server and the Internet.
Every mail server that accepts and relays an SMTP message along the delivery path adds its own Received header field in the message header. The Received header typically contains the domain name and IP address of the mail server that processed the message.
If the Edge Transport server doesn't accept messages directly from the Internet, you need to use the InternalSMTPServers parameter on the Set-TransportConfig cmdlet on an Exchange Mailbox server to identify the IP address of the mail server that sit between the Edge Transport server and the Internet. The IP address data is replicated to Edge Transport servers by EdgeSync. When messages are received by the Edge Transport server, the Connection Filtering agent assumes an IP address in a Received header field that doesn't match a value specified by the InternalSMTPServers parameter is the source IP address that needs to be checked. Therefore, you need specify all internal SMTP servers in order for connection filtering to function correctly.