Anti-Spam Connection Filtering when installed on Hub servers and other AS configuration misunderstandings

Recently I came across a situation where it was reported that Connection Filtering stopped working (IPs on the Blocklist and RBLs were no longer being blocked). The solution led me to write this blog to clarify some confusion about "when" connection filtering is applied and how configuration settings are applied when the agents are installed on a Hub server.

Let's begin by looking at the online documentation regarding Connection Filtering:

"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."

http://technet.microsoft.com/en-us/library/bb123943(EXCHG.80).aspxv-61marf

From this explanation we see 4 things:

1. That Connection Filtering is installed on Edge by default (as are all the other AS agents)
2. Enabled for inbound (ExternalMail) by default
3. For connections that have not authenticated
4. Connection Filtering (and all AS agents) can be disabled/enabled on individual computers

So in the scenario (where connection filtering was no longer blocking) we checked:

1. Get-Transportagent which showed the Connection Filtering agent enabled
2. Get-IPBlocklistconfig which showed True for both Enabled and ExternalMailEnabled (False for InternalMailEnabled - default setting)
3. Get-IpBlocklistentry which contained IPs that should be blocked
4. Confirmed that ActiveDirectory correctly reflected that the agent and config were enabled
5. Agent Logs did not show activity related to the IPs that should be blocked

The missing piece was in understanding that connection filtering is a combination of how the Agents are enabled (noted above) and what rights the connecting SMTP session is granted. Examining the SMTP receive log files indicated that the session was granted all the rights possible (including ByPassAntiSpam) which only occurs with "Externally Secured" Authentication.

So here's the way it works:

When the AS Filter components "Enabled" and "ExternalMailEnabled" parameters are set to true, any mail that comes in from an SMTP Session anonymously or via a Partner may be scanned. If the AS Filter components "Enabled" and "InternalMailEnabled" parameters are set to true, any mail from an authenticated session may be scanned. Note: Authenticated partner sessions are not considered Internal.

So to recap: The following 5 points should be considered when determining whether an AS agent executes against a particular SMTP session.

1) The agent itself must be enabled. i.e. The Connection Filtering agent. Use Get-TransportAgent to determine which agents are installed and enabled/disabled.

2) The Anti-Spam config must be enabled. i.e. Get-IPBlockListconfig | fl enabled

3) Consider whether the Anti-spam component is set for ExternalMailEnabled and/or InternalMailEnabled

Default settings IPAllowListConfig:

4) Anonymous and Partner SMTP Sessions are governed by the ExternalMailEnabled parameter. Authenticated sessions (including connectors that are configured for External Authoritative) are governed by the InternalMailEnabled parameter.

5) What permissions does the submitting client have? i.e. All Exchange Servers and Externally Secured sessions get the Bypass Anti-spam privilege (this cannot be removed). Even when ExternalMailEnabled is true and the SMTP session is anonymous, if NT Authority\Anonymous Logon has the Bypass Anti-Spam associated with the receive connector, mail will not be checked.

Now to dispel some other misunderstandings with regard to Configuration controls

IPAllowlistconfig or IPBlocklistconfig command default settings are below. However, if InternalMailEnabled is set to True...

...no action is taken on trusted servers in the Exchange Organization. For grins, I decided to test this in my lab sending mail from one Hub to another. The sending server passed the X-EXPS Auth command which would be the auth used for "Exchange Servers". In the debug tracing you could see that the IP was checked against the IPBlocklist, but not rejected because the Exchange Servers group is granted ByPassAntispam permissions on the connector.

Configuration Misunderstandings when Anti-Spam Agents are installed on Hub servers

Anti-spam Agents are installed per server by running install-antispamagents.ps1 script.

After running the script you will have Organization level and Server level controls. There are two Anti-Spam Tabs added to the Exchange Management Console, one at the Org level and another at the Server\Hub level.

Organization level settings in the Exchange Management Console:

Server level setting in the Exchange Management Console:

Get-TransportAgent cmdlet is a per Transport server configuration setting. This example has 3 of the agents disabled. So this will only affect the Hub this is configured on:

The cmdlet, Set- Transport server, -AntispamAgentsEnabled, is a bit confusing at first. The default value is True when you run the script to install the agents on a Hub. When set to False, it does not disable the AS agents. It simply hides the Anti-Spam tab at the Server level for that particular Hub server in the Exchange Management Console (may require restart of the msExchangeTransport and close / reopen the console).

The overlooked 'internalSmtpServers' list

Imagine this scenario:

Mail with valid SPF records is rejected by your SenderID Agent. The SPF shows these IP addresses:

contoso.com text =
"v=spf1 ip4:192.168.50.2 ip4:192.168.50.3 ip4:192.168.50.4 -all"

The rejected Message headers are:

Received: From senderserver.contoso.com (192.168.50.3) by hosting1.company.com (192.168.2.3)
Received: From hosting1.company.com (192.168.51.3) by mail02.yourcompany.com (192.168.75.6)
From: sender@contoso.com

Since Exchange has to pick an IP to compare to the SPF records, which one does it pick?

To determine this, Exchange starts with the last "received: From" header in the mail message and looks for a match in the internalSmtpServers list moving up the received: From headers until a match is NOT found. In the example above, "Received: From hosting1.company.com (192.168.51.3) will be the first IP match attempted. The reason the mail was rejected above was that IP was not in the internalSmtpServers list. Adding it then returns a match so the next Recevied:From header is now examined and that IP is not only the last external IP (not in the list of internalSmtpServers) but also on the Sender's SPF records (192.168.50.3) and the mail passes SenderID Agent.

In some scenarios mail is filtered through a hosted service provider that provides services such as Anti-Spam, Anti-Virus. By failing to add the hosted service provider IP addresses to the internalSmtpServers list, it's possible that all inbound mail will cease. Upon investigation you find the following in your Agent Log:

Agent : Connection Filtering Agent
Event : OnEndOfHeaders
Action : RejectMessage
SmtpResponse : 550 5.7.1 External client does not have permissions to submit to this server
Reason : LocalBlockList
ReasonData : machine-generated entry

Machine generated entries are those added by the Sender Reputation Agent. You can get a quick look with the following cmdlet:

PS> get-IPBlockListEntry | {where $_.IsMachineGenerated}

Remember, the internalSmtpServers determines what the 'last external IP' to be used by the AS agents. If incoming mail is filtered through an appliance or hosted service it's imperative that the ip address(s) of those servers be listed here.

When the AS agents are installed but the InternalSmtpServers is not populated, Event 1022 is logged:

Anti-spam agents are enabled and the list of internal SMTP servers is empty. Please use the set-TransportConfig task to populate this list.

Troubleshooting connection filtering

1. Determine if the connecting server authenticated by examining the SMTP protocol receive logs
2. What permissions were ultimately granted to the session (get-adpermission for the receive connector Exchange Extended rights on the user)
3. Check the IPAllowlistconfig or IPBlocklistconfig for how they are enabled
4. Check the IPAllowlistentry and / or IPBlocklistentry
5. Check the individual server settings with Get-Transportagent

Dave Forrest