Introduction
In this post, we’ll look at how Exchange selects a receive connector for a particular client connection. We’ll break down this post into the below sections:
- Default receive connectors
- Receive connector selection
- Example scenarios
For more information on how to check which receive connector is in use by Exchange for a particular connection, see here.
Default receive connectors
When Exchange is installed, there are a number of receive connectors that are set up by default. In Exchange 2013, there are two roles (CAS and MBX) but in Exchange 2016 the CAS and MBX roles cannot be installed separately and are merged into one role called the MBX role.
Exchange 2013 has a Front End Transport Service as part of the CAS role and a Transport Service as part of the MBX role. Multi-role Exchange 2013 servers have both the services.
Exchange 2016 is similar to a multi-role Exchange 2013 server in that it has both transport services.
Front End Transport Service Receive Connectors
The Front End Transport Service has three receive connectors. These only proxy connections to the Transport Service (running on Exchange 2013 or 2016 MBX servers):
- Client Frontend <ServerName>: This receive connector listens on port 587 and is used for authenticated SMTP connections from clients such as POP3 clients. Generally little configuration is done on this receive connector.
- Default Frontend <ServerName>: This receive connector accepts anonymous connections from external SMTP servers on port 25 and is (or should be) the point at which external messages enter the Exchange organization. (No, you should not be using the Transport Service on an Exchange 2013 MBX server to receive external email. It should be proxied through the Front End Transport Service on the CAS server).
- Outbound Proxy Frontend <ServerName>: Yes, outbound. This receive connector is not involved in inbound email delivery to the Exchange organization. It’s only used if you have configured your Send Connector to proxy through your front end CAS server/service and is use for outbound email from your Exchange organization. You enable this when creating or configuring your send connector by setting the FrontendProxyEnabled parameter to enabled on the Set-SendConnector or New-SendConnector cmdlets. This receive connector listens on port 717 for outbound email from the Transport Service in the MBX role.
Generally it’s best to leave these receive connectors as they are and create new receive connectors for specific scenarios such as if you need to configure anonymous relay for a list of client IPs. See here if you need more information on how to configure this.
These Front End Transport Service receive connectors are bound to all local and remote IPv4 and IPv6 addresses by default which means that Exchange will listen for connections from any client IP and to any IP configured on the Exchange server.
Transport Service Receive Connectors
The Transport Service (part of the MBX role) has two receive connectors. These are not on standard ports and they don’t need to be because they don’t receive connections from clients.
- Client Proxy <ServerName>: This receive connector listens on port 465 and accepts authenticated connections that are proxied from the Client Frontend <ServerName> receive connector which is part of the Front End Transport Service.
- Default <ServerName>: This receive connector listens on one of two ports. In Exchange 2013 it listens on port 25 if the MBX role has been installed without the CAS role on the same server and it listens on port 2525 if the CAS and MBX roles are installed on the same server. As Exchange 2016 behaves much like a multi-role Exchange 2013 server, this receive connector listens on port 2525. It is used to accept authenticated connections from the Front End Transport Service, the Transport Service on other MBX servers or connections from Edge Transport Servers. Connections are authenticated using the Exchange server’s self-signed certificate and this is why you shouldn’t delete it. See more here.
As with the Front End Transport Service receive connectors, the Transport Service receive connectors are bound to all local and remote IPv4 and IPv6 addresses which means that Exchange will listen for connections from any IP and to any IP configured on the Exchange server.
Now that we have a better understanding about the default receive connector configuration, we can continue on to receive connector selection.
Receive Connector Selection
As we know, each receive connector includes a number of properties but for the purpose of receive connector selection, we only need to focus on these three properties:
- Port Binding (the TCP on the Exchange server that the receive connector listens on)
- IP Binding (the Exchange server IP that the receive connector listens on)
- Remote IP ranges (the remote IP range that the receive connector accepts connections from)
The Port and IP binding make up the receive connector binding. E.g. a binding of 0.0.0.0:25 means that the receive connector listens on all IPs for connections on port 25.
You cannot have two receive connectors which have all three properties set to be the same – i.e. you cannot have two receive connectors with the same port binding, IP binding and remote IP ranges configured. If you try to do this, you’ll get the error below:
The values that you specified for the Bindings and RemoteIPRanges parameters conflict with the settings on Receive connector “LITEX01Relay 1”. A Receive connector must have a unique combination of a local IP address & port bindings and remote IP address ranges. Change at least one of these values.
There needs to be a difference so that Exchange can select the correct receive connector for the incoming client connection.
While we’re here, let’s also define what an SMTP client is. SMTP clients include:
- Other servers relaying through Exchange using authenticated or anonymous relay
- Other Exchange organizations sending email through to your organization
- Incoming external email directly from the internet or via a smart host (mail gateway or mail filter)
- End user clients which are using SMTP to send email using a POP3 client
Now that we have enough background information, we can start to look at the receive connector selection process. This involves the four steps below:
- Step 1: Get all receive connectors where the network adapter bindings include the port on the Exchange server that the client is connecting to
- Step 2: Get all receive connectors identified in step 1 where the network adapter bindings include the IP on the Exchange server that the client is connecting to
- Step 3: If step 2 identifies more than one receive connector, select the receive connector with the most specific remote IP range which includes the client IP
- Step 4: If step 3 identifies more than one receive connector, select the receive connector with the most specific IP binding
Example scenarios
In order to explain the selection process, I’ve made up some scenarios and I’ll demonstrate how to figure out the receive connector that is used. In each scenario, we have all the default receive connectors as per the default configuration above but we also have a three custom receive connectors with the below settings:
Custom receive connector 1:
- Name: Relay 1
- Port Binding: 25
- IP Binding: All available IPv4 and IPv6 addresses
- Remote IP Ranges: 10.2.0.10 – 10.2.0.11 (IP range)
Custom receive connector 2:
- Name: Relay 2
- Port Binding: 25
- IP Binding: All available IPv4 and IPv6 addresses
- Remote IP Ranges: 10.2.0.10 and 10.2.0.11 (individual IPs)
Custom receive connector 3:
- Name: Relay 3
- Port Binding: 25
- IP Binding: 10.2.0.21
- Remote IP Ranges: 10.2.0.10 and 10.2.0.11 (individual IPs)
In the below scenarios, our server is either an Exchange 2013 CAS server, an Exchange 2013 multi-role server or an Exchange 2016 server as these all behave the same way in these scenarios. In each scenario, our Exchange server has an IP of 10.2.0.21 and hostname LITEX01.
Scenario 1: A client with IP 105.10.10.10 connects to the Exchange server on port 587 and IP 10.2.0.21 (through the firewall using a NAT rule):
Step 1: Get all receive connectors where the network adapter bindings include the port on the Exchange server that the client is connecting to
When we look through all the receive connectors on the server, we can see that there is only one receive connector bound to port 587: Client Frontend LITEX01
Step 2: Get all receive connectors indentified in step 1 where the network adapter bindings include the IP on the Exchange server that the client is connecting to
Our client is connecting to 10.2.0.21 and the Client Frontend LITEX01 receive connector is bound to all IPv4 and IPv6 IPs so this matches.
Step 3: If step 2 identifies more than one receive connector, select the receive connector with the most specific remote IP range which includes the client IP
We only identified one receive connector in step 2 so we skip this step.
Step 4: If step 3 identifies more than one receive connector, select the receive connector with the most specific IP binding
We only identified one receive connector in step 3 so we skip this step.
Result: The receive connector that is selected is the Client Frontend LITEX01 receive connector.
Scenario 2: A client with IP 105.10.10.10 connects to the Exchange server on port 25 and IP 10.2.0.21 (through the firewall using a NAT rule):
Step 1: Get all receive connectors where the network adapter bindings include the port on the Exchange server that the client is connecting to
When we look through all the receive connectors on the server, we can see that there are four receive connectors bound to port 25:
- Default Frontend LITEX01
- Relay 1
- Relay 2
- Relay 3
Step 2: Get all receive connectors indentified in step 1 where the network adapter bindings include the IP on the Exchange server that the client is connecting to
The client is connecting to the server on IP 10.2.0.21. All of the receive connectors identified in step 1 are bound to either all IPv4 and IPv6 addresses or to just 10.2.0.21 so they all include the IP the client is connecting to:
- Default Frontend LITEX01
- Relay 1
- Relay 2
- Relay 3
Step 3: If step 2 identifies more than one receive connector, select the receive connector with the most specific remote IP range which includes the client IP
Relay 1 has a remote IP range which only includes 10.2.0.10 – 10.2.0.11 so cannot be used by the client. Relay 2 has a remote IP range which only includes 10.2.0.10 and 10.2.0.11 so also cannot be used by the client. Relay 3 also has a remote IP range which includes 10.2.0.10 and 10.2.0.11 so also cannot be used by the client. This leaves Default Frontend LITEX01 which has a remote IP range which includes all IPv4 and IPv6 addresses so this is the selected receive connector.
Step 4: If step 3 identifies more than one receive connector, select the receive connector with the most specific IP binding
We only identified one receive connector in step 3 so we skip this step.
Result: The receive connector that is selected is the Default Frontend LITEX01 receive connector.
Scenario 3: A client with IP 10.2.0.10 connects to the Exchange server on port 25 and IP 10.2.0.21
Step 1: Get all receive connectors where the network adapter bindings include the port on the Exchange server that the client is connecting to
When we look through all the receive connectors on the server, we can see that there are four receive connectors bound to port 25:
- Default Frontend LITEX01
- Relay 1
- Relay 2
- Relay 3
Step 2: Get all receive connectors indentified in step 1 where the network adapter bindings include the IP on the Exchange server that the client is connecting to
The client is connecting to the server on IP 10.2.0.21. All of the receive connectors identified in step 1 are bound to either all IPv4 and IPv6 addresses or to just 10.2.0.21 so they all include the IP the client is connecting to:
- Default Frontend LITEX01
- Relay 1
- Relay 2
- Relay 3
Step 3: If step 2 identifies more than one receive connector, select the receive connector with the most specific remote IP range which includes the client IP
Relay 1 has a remote IP range set to 10.2.0.10 – 10.2.0.11 so this includes the client IP. Relay 2 has a remote IP range which includes 10.2.0.10 and 10.2.0.11. Relay 3 has a remote IP range which also includes 10.2.0.10 and 10.2.0.11. Default Frontend LITEX01 has a remote IP range which includes all IPv4 and IPv6 addresses so can also be used by the client.
We need to select the most specific IP range that includes the client IP. In this case we have a tie between Relay 2 and Relay 3 which both only have two IPs in the remote IP range whereas Default Frontend LITEX01 includes all IPv4 and IPv6 addresses. Now, your question is “why is Relay 1 not included in this tie? Surely it also includes the same two remote IPs as Relay 2 and Relay 3?” The answer is that you need to look at the range that the IP is in. For receive connector Relay 1 the IP 10.2.0.10 is in a range of two IPs (10.2.0.10 – 10.2.0.11) whereas for receive connectors Relay 2 and Relay 3, the IP 10.2.0.10 is in a range of just one IP (i.e. the two IPs are added as two IP ranges of one IP each). This makes Relay 2 and Relay 3 more specific than Relay 1. So, now we are down to these two receive connectors:
- Relay 2
- Relay 3
Step 4: If step 3 identifies more than one receive connector, select the receive connector with the most specific IP binding
Now, which receive connector is actually being used? Well, this is where we look at the IP binding. Relay 2 is bound to all IPv4 and IPv6 addresses whereas Relay 3 is bound to only 10.2.0.21 making it more specific.
Result: The receive connector that is selected is the Relay 3 receive connector.
Conclusion
In this post, we’ve looked at the default receive connectors that are configured when you first install your Exchange 2013 or 2016 server. We’ve also discussed how a receive connector is selected according to client IP and receive connector IP and port bindings.