Exchange Server 2010 : Setting Up Message Routing (part 3) - Using and Configuring Receive Connectors

4. Using and Configuring Receive Connectors

Exchange Server 2010 Hub Transport and Edge Transport servers use Receive connectors to receive messages from the Internet, from email clients, and from other email servers. A Receive connector controls inbound connections to your Exchange organization. The Receive connectors you require on a Hub Transport server for internal mail flow are, by default, automatically created when the Hub Transport server role is installed. A Receive connector that can receive email from the Internet (and from Hub Transport servers) is automatically created when the Edge Transport server role is installed. End-to-end mail flow can be implemented by subscribing an Edge Transport server to your Active Directory site by using the Edge subscription process. Other scenarios, such as an unsubscribed Edge Transport server, require manual connector configuration to establish end-to-end mail flow.

In Exchange Server 2010, the Receive connector listens for inbound connections that match its settings, such as connections that are received through a particular local IP address and port or from a specified IP address range. You create Receive connectors when you want to control which servers receive messages from a particular IP address or IP address range and when you want to configure special connector properties for messages that are received from a particular IP address, such as specifying a larger message size, more recipients per message, or more inbound connections.

Receive connectors are scoped to a single server and determine how that specific server listens for connections. When you create a Receive connector on a Hub Transport server, it is stored in Active Directory as a child object of the server on which it is created. When you create a Receive connector on an Edge Transport server, it is stored in AD LDS on that server.

If you need additional Receive connectors for specific scenarios, you can create them by using the EMS. Each Receive connector uses a unique combination of IP address bindings, port number assignment, and remote IP address ranges from which mail will be accepted by this connector.

4.1. Default Receive Connectors Created During Setup

When you install the Hub Transport server role, two Receive connectors are created. Typically, additional Receive connectors are not required, and in most cases the default Receive connectors do not require reconfiguration change. You can, however, amend default Receive connector settings or create additional Receive connectors if you consider it appropriate to do so.

The default Receive connectors created when the Hub Transport server role is installed are named Client <servername> and Default <servername>, for example, Client VAN-EX1 and Default VAN-EX1. The Client <servername> Receive connector accepts SMTP connections from all non–Messaging Application Programming Interface (MAPI) clients, such as POP and IMAP. The configuration of the Client <servername> Receive connector is as follows:

• Status: Enabled.

• Protocol logging level: None.

• Connector FQDN: Servername.forestroot.extension (for example, VAN-EX1.adatum.com).

• Bindings: All available IP addresses. The server accepts mail received through any network adapter on the Hub Transport server.

• Port: 587. This is the default port for receiving messages from all non-MAPI clients for SMTP relay.

• Remote server IP address range: 0.0.0.0 through 255.255.255.255 for IPv4 and 0000:0000:0000:0000:0000:0000:0.0.0.0 through ffff:ffff:ffff:ffff:ffff:ffff:255.255.255.255 for IPv6. The Hub Transport server accepts mail from any IP address.

• Available authentication methods: TLS, Basic authentication, Exchange Server authentication, Integrated Windows authentication.

• Permission groups: Exchange users.

The Default <servername> Receive connector accepts connections from other Hub Transport servers and any Edge Transport servers in your organization. The configuration of the Default <servername> Receive connector is as follows:

• Status: Enabled.

• Protocol logging level: None.

• Connector FQDN: Servername.forestroot.extension

• Local server Receive connector bindings: All available IP addresses. The server accepts mail received through any network adapter on the Hub Transport server.

• Port: 25.

• Remote server IP address range: 0.0.0.0 through 255.255.255.255 for IPv4 and 0000:0000:0000:0000:0000:0000:0.0.0.0 through ffff:ffff:ffff:ffff:ffff:ffff:255.255.255.255 for IPv6. The Hub Transport server accepts mail from any IP address.

• Available authentication methods: TLS, Basic authentication, Integrated Windows authentication.

• Permission groups: Exchange users, Exchange servers, Legacy Exchange servers.

During installation of the Edge Transport server role, one Receive connector is created. This is configured to accept SMTP communications from all IP address ranges and is bound to all IP addresses on the local server. It is configured to have the Internet usage type and accepts anonymous connections. Typically, no additional Receive connectors are required on an Edge Transport server. If you use EdgeSync, you do not need to make any configuration changes because the Edge subscription process automatically configures permissions and authentication mechanisms. Anonymous sessions and authenticated sessions are granted different permission sets.

Get-ReceiveConnector

Figure 6 shows the output from this command entered on the VAN-EX1 Hub Transport server. This lists the two connectors created by default when this server was added to the Hub Transport role. The other Receive connectors listed were created during experimentation and are unlikely to be configured on your test network.

4.2. Receive Connector Usage Types

As with Send connectors, the usage type of a Receive connector determines the default security settings for that connector and hence specifies the permissions that are granted to sessions that connect to that connector and the supported authentication mechanisms.

When you use the New-ReceiveConnector EMS cmdlet to create a Receive connector, you can specify the usage type by using the Usage parameter or by specifying the usage type directly with the appropriate parameter switch, such as Custom.

The valid Receive connector usage types are Client, Custom, Internal, Internet, and Partner. You need to supply a value for the Bindings parameter if you specify the Internet, Partner, or Custom usage type. You need to supply a value for the RemoteIPRanges parameter if you specify the Client, Internal, Partner, or Custom usage type. If you do not specify a value for a required parameter, the command ends unsuccessfully and does not prompt you for the missing required parameters.

You would configure the Internet usage type for a Receive connector on an Edge Transport server that is receiving email from the Internet. If a Hub Transport server was Internet facing, you would also specify this usage type; however, Internet-facing Hub Transport servers are not recommended.

You would configure the Internal usage type for a Receive connector on a Hub Transport server that is receiving email from a Hub Transport server in another forest (you can also use the Custom usage type for cross-forest connections), from a message transfer agent (MTA), or from an Exchange Server 2003 bridgehead server in the same forest (in which case a routing group must also exist). You would also configure this usage type on an Edge Transport server that is receiving email from a Hub Transport server or from an Exchange Server 2003 bridgehead server that is configured to use the Edge Transport server as a smart host.

A Receive connector with the Client usage type is automatically created on every Hub Transport server when the role is installed. By default, this Receive connector is configured to receive email through TCP port 587.

You would configure the Custom usage type for a Receive connector on a Hub Transport server receiving email from a Hub Transport server or an Exchange Server 2003 bridgehead server in another forest. You would also configure this usage type for a Receive connector on an Edge Transport server receiving email from a third-party MTA, an external relay domain, or an Exchange Hosted Services server.

You would configure the Partner usage type for a Receive connector on a Hub Transport server receiving email from a domain with which you have established MTLS authentication.

4.3. Creating and Configuring a Receive Connector

If you need to create and configure Receive connectors for specific purposes, you can use commands based on the New-ReceiveConnector and Set-ReceiveConnector EMS cmdlets.

For example, the following command creates the Receive connector ReceiveConnector01 with the Custom usage type; this connector listens for incoming SMTP connections on the IP address 10.10.10.1 and port 25 and accepts incoming SMTP connections only from the IP range 192.168.8.1 through 192.168.8.127:

New-ReceiveConnector -Name ReceiveConnector01 -Usage Custom -Bindings 10.10.10.1:25
-RemoteIPRanges 192.168.8.1-192.168.8.127

					  

Note that the Bindings parameter specifies the local Hub or Edge Transport server IP address and the port through which the Receive connector accepts connections. These settings bind the Receive connector to a particular network adapter and TCP port on the Hub or Edge Transport server. By default, a Receive connector is configured to use all available network adapters and TCP port 25. If the server on which it is created has multiple network adapters, you may want the Receive connector to be bound to a particular network adapter or to accept connections through an alternative port. For example, you may want to configure one Receive connector on an Edge Transport server to accept anonymous connections through an external network adapter and to configure a second Receive connector on the server to accept connections only from local Hub Transport servers through the internal network adapter.

The IP address or IP address range for the remote servers from which a Receive connector will accept inbound connections, as specified by the RemoteIPRanges parameter, can use one of the following formats:

• IP address For example, 192.168.20.1

• IP address range For example, 192.168.20.10-192.16820.20

• IP address with subnet mask For example, 192.168.20.0(255.255.255.0)

• IP address with Classless Interdomain Routing notation subnet mask For example, 192.168.1.0/24

The following EMS command sets the authentication mechanism of the Receive connector ReceiveConnector01 to Integrated Windows authentication:

Set-ReceiveConnector -Identity ReceiveConnector01 -AuthMechanism Integrated

The usage type you specify for a Receive connector defines its default authentication method, but you can use the Set-ReceiveConnector EMS cmdlet with the AuthMechanism parameter as in the previous command to configure one of the following mechanisms:

• None

• TLS

• Integrated

• BasicAuth

• BasicAuthRequireTLS

• ExchangeServer

• ExternalAuthoritative

Typically, you create and configure additional Receive connectors in order to specify a maximum message size, a connection time-out, or a connection activity time-out for traffic from specified IP addresses where these settings are different from those specified by default Receive connectors. The following EMS command specifies a maximum message size of 100 MB, a connection time-out of 20 minutes, and a connection inactivity time-out of 15 minutes for the ReceiveConnector01 Receive connector (note that the connection time-out must be greater than the connection inactivity time-out):

Set-ReceiveConnector -Identity ReceiveConnector01 -MaxMessageSize 100MB
-ConnectionTimeout 00:20:00 -ConnectionInactivityTimeout 00:15:00

When you have made significant configuration changes to a Receive connector, it is a good idea to list these configuration changes and check for errors. The following command displays the configuration changes made on the Receive connector ReceiveConnector01:

Get-ReceiveConnector -Identity ReceiveConnector01 | FL Identity,AuthMechanism,Bindings,
ConnectionTimeout,ConnectionInactivityTimeout,MaxMessageSize

					  

Figure 7 shows the output from this command.

Finally, if you no longer need a Receive connector, you can delete it—note that this is not the same as temporarily disabling it. The following command deletes the Receive connector ReceiveConnector01:

Remove-ReceiveConnector -Identity ReceiveConnector01

Anonymous relay on Internet SMTP messaging servers is a serious security risk that could be (and probably will be) exploited by unsolicited commercial email senders to hide the source of their messages. Therefore, you need to place restrictions on Internet-facing messaging servers to prevent relaying to unauthorized destinations.

In Exchange Server 2010, you typically tackle this problem by configuring accepted domains on Edge Transport server or Hub Transport servers. Accepted domains can be authoritative, internal relay, and external relay.

In Exchange Server 2010, an accepted SMTP domain is considered authoritative when the Exchange organization hosts mailboxes for recipients in this domain. The Edge Transport servers should always accept email that is addressed to any of the organization’s authoritative domains. By default, when the first Hub Transport server role is installed, one accepted domain is configured as authoritative for the Exchange organization. The default accepted domain is the FQDN for your forest root domain. If your internal domain name differs from the external domain name, you must create an accepted domain to match your external domain name. No accepted domains are configured by default on Edge Transport servers.

When an Edge Transport server receives email from the Internet and the recipient of the message is not part of an authoritative domain, the sending server attempts to relay the message through the Exchange server. When a server acts as a relay server that has no restrictions, this can put a large burden on Internet-connected servers. You can prevent this open relay scenario by rejecting all email that is not addressed to a recipient in your organization’s authoritative domains. However, there are scenarios in which an organization wants to let partners or subsidiaries relay email through their Exchange servers. In Exchange Server 2010, you can configure accepted domains as relay domains. Your organization receives the email messages and then relays the messages to another email server.

You can configure a relay domain as an internal relay domain or as an external relay domain. When you configure an internal relay domain, some or all of the recipients in this domain do not have mailboxes in your Exchange organization. Email from the Internet is relayed for this domain through your Hub Transport servers. To support this scenario, you need to create an accepted domain that is configured as an internal relay domain. The accepted domain that is configured as an internal relay domain first tries to deliver to a recipient in the Exchange organization. If the recipient is not found, the message is routed to the Send connector that has the closest address space match.

When you configure an external relay domain, messages are relayed by an Edge Transport server to an email server that is outside the Exchange organization and outside the organization’s network perimeter. In this scenario, the MX resource record for the external relay domain references a public IP address for the Exchange Server 2010 organization that is relaying messages. The Edge Transport server receives the messages for recipients in the external relay domain and then routes the messages to the email system for the external relay domain. You need to configure a Send connector from the Edge Transport server to the external relay domain. The external relay domain may also use your organization’s Edge Transport server as a smart host for outgoing mail.

• For local network settings, restrict the Receive connector to listen only on the appropriate network adapter on the Hub Transport or Edge Transport server.

• For remote network settings, restrict the Receive connector so that it accepts connections only from a specified server or servers. This restriction is necessary because this Receive connector is configured to accept relay from anonymous users. Restricting the source servers by IP address is the only measure of protection possible on this Receive connector.