Understanding Receive Connectors

Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2

Receive connectors are configured on computers that are running Microsoft Exchange Server 2010 and that have the Hub Transport server role or Edge Transport server role installed. Receive connectors represent a logical gateway through which all inbound messages are received. This topic provides an overview of Receive connectors and how the configuration of Receive connectors affects individual message processing.

Overview of Receive Connectors

Exchange 2010 transport servers require Receive connectors to receive messages from the Internet, from e-mail clients, and from other e-mail servers. A Receive connector controls inbound connections to the Exchange organization. By default, the Receive connectors that are required for internal mail flow are automatically created when the Hub Transport server role is installed. The Receive connector that's capable of receiving mail from the Internet and from Hub Transport servers is automatically created when the Edge Transport server role is installed. However, end-to-end mail flow is possible only after the Edge Transport server has been subscribed to the Active Directory site by using the Edge Subscription process. Other scenarios, such as an Internet-facing Hub Transport server or an unsubscribed Edge Transport server, require manual connector configuration to establish end-to-end mail flow.

In Exchange 2010, the Receive connector is a receive listener. This means that the connector is listening for inbound connections that match the settings of the Receive connector. A Receive connector listens for connections that are received through a particular local IP address and port, and 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 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, the Receive connector is stored in Active Directory as a child object of the server on which it's created. When you create a Receive connector on an Edge Transport server, the Receive connector is stored in Active Directory Lightweight Directory Services (AD LDS).

If you need additional Receive connectors for specific scenarios, you can create them by using the Exchange Management Console (EMC) or the Exchange Management Shell. Each Receive connector must use a unique combination of IP address bindings, port number assignments, and the remote IP address ranges from which mail will be accepted by this connector.

Default Receive Connectors Created During Setup

Certain Receive connectors are created by default when you install a Hub Transport or Edge Transport server role.

Default Receive Connectors Created on a Hub Transport Server

When you install the Hub Transport server role, two Receive connectors are created. No additional Receive connectors are needed for typical operation, and in most cases the default Receive connectors don't require a configuration change. The usage type and configuration of these connectors are described in the following table.

Default Receive connector configuration on Hub Transport servers

Default Receive Connector Created on an Edge Transport Server

During installation, one Receive connector is created. This Receive connector is configured to accept SMTP communications from all IP address ranges and is bound to all IP addresses of the local server. It's configured to have the Internet usage type, and therefore, the connector accepts anonymous connections. In a typical installation, no additional Receive connectors are required. If you use EdgeSync, you don't 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.

If you don't use EdgeSync, we recommend that you modify the settings of this Receive connector and create an additional Receive connector of the Internal usage type. To complete Receive connector configuration, follow these steps:

1. Modify the settings of the default Receive connector   Set the local network bindings to the IP address of only the Internet-facing network adapter.

2. Create a Receive connector   Select Internal as the connector usage type. Set the local network bindings to the IP address of only the organization-facing network adapter. Configure the remote network settings to receive mail from the remote IP addresses that are assigned to the Hub Transport servers.

   Note

   Any Receive connector that's responsible for accepting connections from Edge Transport servers or other Hub Transport servers must have the Exchange Server authentication method assigned to it. The Exchange Server authentication method is the default authentication method when you create a Receive connector that has the Internal usage type.

3. Determine whether Basic authentication is desired   If you want to support Basic authentication, create a local user account and grant the necessary permissions by using the Add-ADPermission cmdlet.

For more information, see Configure Mail Flow Between an Edge Transport Server and Hub Transport Servers Without Using EdgeSync.

Receive Connector Usage Types

The usage type determines the default security settings for the connector.

The security settings for a Receive connector specify the permissions that are granted to sessions that connect to the Receive connector and the supported authentication mechanisms.

When you use the EMC to configure a Receive connector, the New SMTP Receive Connector wizard prompts you to select the usage type for the connector. You can use two different methods to specify the usage type:

• Use the Usage parameter with the desired value, such as Usage Custom. There are other required parameters based on the usage type that you specify. If you don't specify the required parameters in the New-ReceiveConnector command, the command will fail.

• Use the switch parameter for the desired usage type, such as Custom. There are other required parameters based on the usage type that you specify. If you don't specify the required parameters in the New-ReceiveConnector command, you're prompted for the missing parameter values so the command can continue.

Permission Groups

A permission group is a predefined set of permissions that's granted to well-known security principals and assigned to a Receive connector. Security principals include users, computers, and security groups. A security principal is identified by a security identifier (SID). Permission groups are only available for Receive connectors. The use of permission groups simplifies the configuration of permissions on Receive connectors. The PermissionGroups property defines the groups or roles that can submit messages to the Receive connector and the permissions that are assigned to those groups. The set of permission groups is predefined in Exchange 2010. This means that you can't create additional permission groups. Also, you can't modify the permission group members or the associated permissions.

The following table lists the available permission groups and identifies the security principals and the permissions that are granted when that permission group is configured for a Receive connector.

Receive connector permission groups

Receive Connector Usage Types

The usage type determines the default permission groups that are assigned to the Receive connector and the default authentication mechanisms that are available for session authentication. A Receive connector always responds to a request from a sender to use TLS. The following table describes the available usage types and default settings.

Receive connector usage types

The Receive connector permissions and authentication mechanisms are discussed later in this topic.

Receive Connector Usage Scenarios

Each usage type is appropriate for a specific connection scenario. Select the usage type that has the default settings most applicable to the configuration that you want. You can modify permissions by using the Add-ADPermission and Remove-ADPermission cmdlets. For more information, see the following topics:

• Add-ADPermission

• Remove-ADPermission

The following table lists common connection scenarios and the usage type for each scenario.

Receive Connector usage scenarios

Receive Connector Permissions

Receive connector permissions are assigned to security principals when you specify the permission groups for the connector. When a security principal establishes a session with a Receive connector, the Receive connector permissions determine whether the session is accepted and how the received messages are processed. The following table describes the permissions that can be assigned on a Receive connector to security principals. You can set Receive connector permissions by using the EMC or by using the PermissionGroups parameter with the Set-ReceiveConnector cmdlet in the Shell. To modify the default permissions for a Receive connector, you can also use the Add-ADPermission cmdlet.

Receive connector permissions

Local Network Settings

In the EMC, you use the local network settings for a Receive connector to specify the IP address and port through which the transport server accepts connections. In the Shell, use the Bindings parameter to specify the local IP address and port of the transport server through which the Receive connector accepts connections. These settings bind the Receive connector to a particular network adapter and TCP port on the transport server.

By default, a Receive connector is configured to use all available network adapters and TCP port 25. If a transport server has multiple network adapters, you may want a 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 the Edge Transport server to accept anonymous connections through the external network adapter. A second Receive connector can be configured to accept connections from only Hub Transport servers through the internal network adapter.

Specify the IP address of the network adapter when you configure Receive connector bindings. If the Receive connector is configured to accept connections through a port other than the default, the sending client or server must be configured to send to that port and any firewalls between the message sender and the receiving server must allow network traffic through that port.

The Local Network Settings page of the New SMTP Receive Connector wizard in the EMC includes an option to Specify the FQDN this connector will provide in response to HELO or EHLO. In the Shell, this property is set by using the Fqdn parameter with the Set-ReceiveConnector cmdlet. After an SMTP session is established, an SMTP protocol conversation starts between a sending e-mail server and a receiving e-mail server. The sending e-mail server or client sends the EHLO or HELO SMTP command and its FQDN to the receiving server. In response, the receiving server sends a success code and provides its own FQDN. In Exchange 2010, you can customize the FQDN that's provided by the receiving server if you configure this property on a Receive connector. The FQDN value is displayed to connected messaging servers whenever a destination server name is required, as in the following examples:

• In the default SMTP banner of the Receive connector

• In the most recent Received: header field in the incoming message when the message enters the Hub Transport server or Edge Transport server

• During TLS authentication

Remote Network Settings

In the EMC, you use the remote network settings for a Receive connector to specify the IP address ranges from which this Receive connector accepts connections. In the Shell, you use the RemoteIPRanges parameter to specify the IP address ranges from which this Receive connector accepts connections. By default, Receive connectors are created on Hub Transport servers and Edge Transport servers that allow connections from 0.0.0.0–255.255.255.255, or from every IP address.

If you're configuring a Receive connector for a specific scenario, set the remote network settings to only the IP addresses of the servers that should be allowed the permissions and configuration settings for the Receive connector. Multiple Receive connectors can have overlapping remote IP address ranges as long as one range is completely overlapped by another. When remote IP address ranges overlap, the remote IP address range that has the most specific match to the connecting server's IP address is used.

The IP address or IP address range for the remote servers from which the Receive connector will accept inbound connections is entered in one of the following formats:

• IP address   192.168.1.1

• IP address range   192.168.1.10-192.168.1.20

• IP address together with subnet mask   192.168.1.0(255.255.255.0)

• IP address together with subnet mask by using Classless Interdomain Routing (CIDR) notation   192.168.1.0/24

Receive Connector Authentication Settings

In the EMC, you use the authentication settings for a Receive connector to specify the authentication mechanisms that are supported by the Exchange 2010 transport server. In the Shell, you use the AuthMechanisms parameter to specify the supported authentication mechanisms. You can configure more than one authentication mechanism for a Receive connector. For the authentication mechanisms that are automatically configured for each usage type, see the table labeled "Receive connector usage types" earlier in this topic. The following table lists the available authentication mechanisms for a Receive connector.

Receive connector authentication mechanisms

Additional Receive Connector Properties

The property configuration for a Receive connector defines how e-mail is received through that connector. Not all properties are available in the EMC. For more information about the properties that can be configured by using the Shell, see Set-ReceiveConnector.

Using a Receive Connector for Anonymous Relay

Anonymous relay on Internet SMTP messaging servers is a serious security deficiency that could be exploited by unsolicited commercial e-mail senders, or spammers, to hide the source of their messages. Therefore, restrictions are placed on Internet-facing messaging servers to prevent relaying to unauthorized destinations.

In Exchange 2010, relaying is typically handled by using accepted domains. Accepted domains are configured on the Edge Transport server or Hub Transport server. The accepted domains are additionally classified as internal relay domains or external relay domains. For more information about accepted domains, see Understanding Accepted Domains.

You can also restrict anonymous relay based on the source of the incoming messages. This method is useful when an unauthenticated application or messaging server must use a Hub Transport server or an Edge Transport server as a relay server.

When you create the Receive connector that's configured to allow anonymous relay, you should place the following restrictions on the Receive connector:

• Local network settings   Restrict the Receive connector to listen only on the appropriate network adapter on the Hub Transport server or Edge Transport server.

• Remote network settings   Restrict the Receive connector to accept connections only from the specified server or servers. This restriction is necessary, because the Receive connector is configured to accept relay from anonymous users. Restricting the source servers by IP address is the only measure of protection that's allowed on this Receive connector.

To grant the relay permission to anonymous users on the Receive connector, you can use either of the strategies described later in this topic. Each strategy has advantages and disadvantages. For step by step instructions for both approaches, see Allow Anonymous Relay on a Receive Connector.

Granting Relay Permission to Anonymous Connections

This strategy involves the following tasks:

• Creating a Receive connector with the usage type set to Custom.

• Adding the Anonymous permission group to the Receive connector.

• Assigning the relay permission to the Anonymous Logon security principal on the Receive connector.

The Anonymous permission group grants the following permissions to the Anonymous Logon security principal on the Receive connector:

• Ms-Exch-Accept-Headers-Routing

• Ms-Exch-SMTP-Accept-Any-Sender

• Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender

• Ms-Exch-SMTP-Submit

However, to allow anonymous relay on this Receive connector, you must also grant the following permission to the Anonymous Logon security principal on the Receive connector:

• Ms-Exch-SMTP-Accept-Any-Recipient

The advantage of this strategy is that it grants the minimum required permissions to relay to the specified remote IP addresses.

The disadvantages of this strategy are as follows:

• Additional configuration steps are required to grant the necessary permissions.

• The messages that originate from the specified IP addresses are treated as anonymous messages. Therefore, the messages don't bypass anti-spam checks, don't bypass message size limit checks, and anonymous senders can't be resolved. The process of resolving anonymous senders forces an attempted match between the anonymous sender's e-mail address and the corresponding display name in the global address list (GAL).

Configuring the Receive Connector as Externally Secured

This strategy involves the following tasks:

• Creating a Receive connector with the usage type set to Custom.

• Adding the ExchangeServers permission group to the Receive connector.

• Adding the ExternalAuthoritative authentication mechanism to the Receive connector.

The ExchangeServers permission group is required when you select the ExternalAuthoritative authentication mechanism. This combination of authentication method and permission group grants the following permissions to any incoming connection that's permitted on the Receive connector:

• Ms-Exch-Accept-Headers-Routing

• Ms-Exch-SMTP-Accept-Any-Sender

• Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender

• Ms-Exch-SMTP-Submit

• Ms-Exch-Accept-Exch50

• Ms-Exch-Bypass-Anti-Spam

• Ms-Exch-Bypass-Message-Size-Limit

• Ms-Exch-SMTP-Accept-Any-Recipient

• Ms-Exch-SMTP-Accept-Authentication-Flag

The advantages of this strategy are as follows:

• Ease of configuration

• The messages that originate from the specified IP addresses are treated as authenticated messages. The messages bypass anti-spam checks, bypass message size limit checks, and can resolve anonymous senders.

The disadvantage of this strategy is that the remote IP addresses are considered completely trustworthy. The permissions that are granted to the remote IP addresses allow the remote messaging server to submit messages as if they originated from internal senders within your Exchange organization.

New Features in Exchange 2010 Service Pack 1

In Service Pack 1 (SP1) for Exchange Server 2010, new functionality was added to Receive connectors. This section provides an overview of these new features.

Bare Line Feed Control

When a mail server establishes an SMTP session, it issues SMTP commands to send messages. After specifying the sender and recipient information, the sending server transmits the contents of the message using the DATA command. The content that is transmitted after issuing the DATA command is known as the data stream. The data stream is terminated by a special sequence of characters: a carriage return line feed (CRLF), followed by a period, followed by another CRLF.

Line feed (LF) characters that aren’t immediately preceded by carriage return (CR) characters are known as bare line feeds. Bare line feeds aren’t allowed in SMTP communications. Although it may be possible for a message containing a bare line feed to be delivered successfully, such messages don't adhere to the SMTP protocol standards and may cause problems with messaging servers.

In Exchange 2010 SP1, you can configure your Receive connectors to reject any messages that contain bare line feeds in their data stream. This behavior is controlled by the BareLineFeedRejectionEnabled parameter of the Set-ReceiveConnector cmdlet. By default, this setting is disabled to maintain backwards compatibility. For more information about configuring this parameter, see Set-ReceiveConnector.

Extended Protection Capability

Windows offers channel binding to protect NTLM authentication over encrypted channels from authentication relay attacks. In Exchange 2010, all services provided by Exchange have been updated to support Extended Protection for Authentication. To support this feature in Transport, the Receive connectors have been updated. You can allow, require, or disable Extended Protection for Authentication on your Receive connectors.

You can use the ExtendedProtectionPolicy and ExtendedProtectionTlsTerminatedAtProxy parameters of the Set-ReceiveConnector cmdlet to control how your Transport servers handle extended protection. You can configure a Receive connector to allow or require extended protection. When you configure a Receive connector to require extended protection, any incoming connections from hosts that don't support extended protection will be rejected. To maintain backwards compatibility, the extended protection is disabled by default. For more information about configuring extended protection on your Receive connectors, see Set-ReceiveConnector.

To learn more about extended protection, see the following resources:

• Microsoft Knowledge Base article 973811, Microsoft Security Advisory: Extended protection for authentication

• MSDN Library topic, Integrated Windows Authentication with Extended Protection

 © 2010 Microsoft Corporation. All rights reserved.