Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Topic Last Modified: 2009-09-02

Receive connectors are configured on computers that are running Microsoft Exchange Server 2007 and that have the Hub Transport and Edge Transport server roles 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 2007 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 is 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 directory service 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. For more information, see the following topics:

In Exchange 2007, 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.

Note:
If Exchange 2007 Service Pack 1 (SP1) is deployed on a computer that is running Windows Server 2008, you can enter IP addresses and IP address ranges in the Internet Protocol Version 4 (IPv4) format, Internet Protocol Version 6 (IPv6) format, or both formats. A default installation of Windows Server 2008 enables support for IPv4 and IPv6. For more information about Exchange 2007 SP1 support for IPv6 addresses, see IPv6 Support in Exchange 2007 SP1 and SP2.

Note:

If Exchange 2007 Service Pack 1 (SP1) is deployed on a computer that is running Windows Server 2008, you can enter IP addresses and IP address ranges in the Internet Protocol Version 4 (IPv4) format, Internet Protocol Version 6 (IPv6) format, or both formats. A default installation of Windows Server 2008 enables support for IPv4 and IPv6. For more information about Exchange 2007 SP1 support for IPv6 addresses, see IPv6 Support in Exchange 2007 SP1 and SP2.

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 the Active Directory directory service as a child object of the server on which it is created. When you create a Receive connector on an Edge Transport server, the Receive connector is stored in Active Directory Application Mode (ADAM).

If you need additional Receive connectors for specific scenarios, you can create them by using the Exchange Management Console or 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.

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 Exchange Management Console to configure a Receive connector, the New SMTP Receive Connector wizard prompts you to select the usage type for the connector.

In the release to manufacturing (RTM) version of Exchange 2007, you can also specify the Usage parameter when you create a Receive connector by using the New-ReceiveConnector cmdlet in Exchange Management Shell. However, in Exchange 2007 RTM, Usage is not a required parameter. If you do not specify a usage type when you run the New-ReceiveConnector cmdlet, the default usage type will be set to Custom.

In Exchange 2007 Service Pack 1 (SP1), you must specify a usage type when you create a Receive connector by using the New-ReceiveConnector cmdlet in the Exchange Management Shell. In Exchange 2007 SP1, 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 are prompted for the missing parameter values so the command can continue.

Permission Groups

A permission group is a predefined set of permissions that is 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 2007. This means that you cannot create additional permission groups. Also, you cannot modify the permission group members or the associated permissions.

Table 1 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.

Table 1 Receive connector permission groups

Permission group name	Associated security principals (SIDs)	Permissions granted
Anonymous	Anonymous user account	Ms-Exch-SMTP-Submit Ms-Exch-SMTP-Accept-Any-Sender Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender Ms-Exch-Accept-Headers-Routing
ExchangeUsers	Authenticated user accounts	Ms-Exch-SMTP-Submit Ms-Exch-SMTP-Accept-Any-Recipient Ms-Exch-Bypass-Anti-Spam Ms-Exch-Accept-Headers-Routing
ExchangeServers	Hub Transport servers Edge Transport servers Exchange Servers (Hub Transport server only) Externally Secured servers	Ms-Exch-SMTP-Submit Ms-Exch-SMTP-Accept-Any-Sender Ms-Exch-SMTP-Accept-Any-Recipient Ms-Exch-Accept-Authoritative-Domain-Sender Ms-Exch-Bypass-Anti-Spam Ms-Exch-SMTP-Accept-Authentication-Flag Ms-Exch-Bypass-Message-Size-Limit Ms-Exch-Accept-Headers-Routing Ms-Exch-Accept-Exch50 Ms-Exch-Accept-Headers-Organization (Note: this permission is not granted to Externally Secured servers.) Ms-Exch-Accept-Headers-Forest (Note: this permission is not granted to Externally Secured servers)
ExchangeLegacyServers	Exchange Legacy Interop security group	Ms-Exch-SMTP-Submit Ms-Exch-SMTP-Accept-Any-Sender Ms-Exch-SMTP-Accept-Any-Recipient Ms-Exch-Accept-Authoritative-Domain-Sender Ms-Exch-Bypass-Anti-Spam Ms-Exch-SMTP-Accept-Authentication-Flag Ms-Exch-Bypass-Message-Size-Limit Ms-Exch-Accept-Headers-Routing Ms-Exch-Accept-Exch50
Partner	Partner Server account	Ms-Exch-SMTP-Submit Ms-Exch-Accept-Headers-Routing

Note:
We strongly recommend against configuring Receive connectors to accept anonymous connections from unknown IPv6 addresses. If you configure a Receive connector to accept anonymous connections from unknown IPv6 addresses, the amount of spam that enters your organization is likely to increase. Currently, there is no broadly accepted industry standard protocol for looking up IPv6 addresses. Most IP Block List providers do not support IPv6 addresses. Therefore, if you allow anonymous connections from unknown IPv6 addresses on a Receive connector, you increase the chance that spammers will bypass IP Block List providers and successfully deliver spam into your organization. For more information about Exchange 2007 SP1 support for IPv6 addresses, see IPv6 Support in Exchange 2007 SP1 and SP2.

Note:

We strongly recommend against configuring Receive connectors to accept anonymous connections from unknown IPv6 addresses. If you configure a Receive connector to accept anonymous connections from unknown IPv6 addresses, the amount of spam that enters your organization is likely to increase. Currently, there is no broadly accepted industry standard protocol for looking up IPv6 addresses. Most IP Block List providers do not support IPv6 addresses. Therefore, if you allow anonymous connections from unknown IPv6 addresses on a Receive connector, you increase the chance that spammers will bypass IP Block List providers and successfully deliver spam into your organization.

For more information about Exchange 2007 SP1 support for IPv6 addresses, see IPv6 Support in Exchange 2007 SP1 and SP2.

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 Transport Layer Security (TLS). Table 2 describes the available usage types and default settings.

Table 2 Receive connector usage types

Usage type	Default permission groups	Default authentication mechanism
Client (unavailable on Edge Transport servers)	ExchangeUsers	TLS Basic authentication plus TLS Integrated Windows authentication
Custom	None	None
Internal	ExchangeServers ExchangeLegacyServers (This permission group is unavailable on Edge Transport servers.)	Exchange Server authentication
Internet	AnonymousUsers Partner	None or Externally Secured
Partner	Partner	Not applicable. This usage type is selected when you establish mutual TLS with a remote domain.

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:

Table 3 lists common connection scenarios and the usage type for each scenario.

Table 3 Receive Connector usage scenarios

Connector scenario	Usage type	Comment
Edge Transport server receiving e-mail from the Internet	Internet	A Receive connector that is configured to accept e-mail from all domains is created automatically when the Edge Transport server role is installed.
Hub Transport server receiving e-mail from the Internet	Internet	This is not a recommended configuration. For more information, see How to Configure Connectors for Internet Mail Flow.
Edge Transport server receiving e-mail from an Exchange Server 2003 or Exchange 2000 Server bridgehead server	Internal	In this scenario, the Exchange 2003 or Exchange 2000 bridgehead server is configured to use the Edge Transport server as a smart host for a Send connector.
Hub Transport server receiving e-mail submissions from a client application that uses Post Office Protocol version 3 (POP3) or IMAP4	Client	This Receive connector is automatically created on every Hub Transport server when the role is installed. By default, this Receive connector is configured to receive e-mail through TCP Port 587.
Hub Transport server receiving e-mail from a Hub Transport server	Internal	You do not have to configure Receive connectors between Hub Transport servers within the same organization. This usage type can be used to configure a cross-forest Receive connector.
Hub Transport server receiving e-mail from an Exchange 2003 or Exchange 2000 bridgehead server in the same forest	Internal	This is an optional configuration. Transport between Exchange 2007 and earlier versions of Exchange Server is accomplished through two-way routing group connectors. If you create Simple Mail Transfer Protocol (SMTP) connectors to Exchange 2003 or Exchange 2000 routing groups, a routing group connector must also exist. For more information, see How to Create Routing Group Connectors from Exchange 2007 to Exchange Server 2003
Edge Transport server receiving e-mail from a Hub Transport server	Internal	A Receive connector that is configured to accept e-mail from all domains is created automatically when the Edge Transport server role is installed. You can create another connector and configure it to receive e-mail only from the Exchange organization.
Cross-forest Receive connector for a Hub Transport server in one forest receiving e-mail from a Hub Transport server in a second forest	Custom	For detailed configuration steps, see Configuring Cross-Forest Connectors.
Cross-forest Receive connector for a Hub Transport server in one forest receiving e-mail from an Exchange 2003 or Exchange 2000 bridgehead server in a second forest	Custom	For detailed configuration steps, see Configuring Cross-Forest Connectors.
Hub Transport server receiving e-mail from a third-party message transfer agent	Internal	Specify the IP address range from which messages will be accepted and set the authentication mechanism to either Basic authentication or Externally Secured. For more information, see How to Configure Connectors for Internet Mail Flow.
Edge Transport server receiving e-mail from a third-party message transfer agent	Custom	Use the Add-AdPermission cmdlet to set the extended rights. Specify the IP address range from which messages will be accepted and set the authentication mechanism to Basic authentication. You can also select the Internal usage type and set Externally Secured as the authentication method. No additional permissions configuration is required if you select this option.
Edge Transport server receiving e-mail from an external relay domain	Custom	The Edge Transport server can accept e-mail from an external relay domain and then relay to the destination recipient domain. Specify the IP address range from which messages will be accepted, set the appropriate authentication mechanism, and use the Add-AdPermission cmdlet to set the extended rights.
Edge Transport server receiving e-mail from a domain to which you have established mutual TLS authentication	Partner	Mutual TLS authentication functions correctly only if the following conditions are true: The value of the DomainSecureEnabled parameter is set to `$True`. The value of the AuthMechanism parameter contains `TLS` and cannot contain `External`. The TLSReceiveDomainSecureList parameter in the Get-TransportConfig cmdlet contains at least one domain that is serviced by this Receive connector. The wildcard character () is not supported in domains that are configured for mutual TLS authentication. The same domain must also be defined on the corresponding Send connector, and in the value of the TLSSendDomainSecureList* parameter in the Get-TransportConfig cmdlet. For more information, see Set-ReceiveConnector and Managing Domain Security.
Edge Transport server receiving connections from Microsoft Exchange Hosted Services server	Custom	The Exchange Hosted Services server can act as an externally authoritative server. To use the Externally Secured authentication mechanism, use the Set-ReceiveConnector cmdlet to set the PermissionGroup parameter to `ExchangeServers`.
Hub Transport server receiving connections from an Exchange Hosted Services server	Custom	The Exchange Hosted Services server can act as an externally authoritative server. To use the Externally Secured authentication mechanism, use the Set-ReceiveConnector cmdlet to set the PermissionGroup parameter to `ExchangeServers`.

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. Table 4 describes the permissions that can be assigned on a Receive connector to security principals. You can set Receive connector permissions by using the Exchange Management Console or by using the PermissionGroups parameter with the Set-ReceiveConnector cmdlet in the Exchange Management Shell. To modify the default permissions for a Receive connector, you can also use the Add-AdPermission cmdlet.

Table 4 Receive connector permissions

Receive Connector Permission	Description
ms-Exch-SMTP-Submit	The session must be granted this permission or it will be unable to submit messages to this Receive connector. If a session does not have this permission, the MAIL FROM and AUTH commands will fail.
ms-Exch-SMTP-Accept-Any-Recipient	This permission allows the session to relay messages through this connector. If this permission is not granted, only messages that are addressed to recipients in accepted domains are accepted by this connector.
ms-Exch-SMTP-Accept-Any-Sender	This permission allows the session to bypass the sender address spoofing check.
ms-Exch-SMTP-Accept-Authoritative-Domain-Sender	This permission allows senders that have e-mail addresses in authoritative domains to establish a session to this Receive connector.
ms-Exch-SMTP-Accept-Authentication-Flag	This permission allows Exchange 2003 servers to submit messages from internal senders. Exchange 2007 will recognize the messages as being internal. The sender can declare the message as "trusted". Messages that enter your Exchange system through anonymous submissions will be relayed through your Exchange organization with this flag in an untrusted state.
ms-Exch-Accept-Headers-Routing	This permission allows the session to submit a message that has all received headers intact. If this permission is not granted, the server will strip all received headers.
ms-Exch-Accept-Headers-Organization	This permission allows the session to submit a message that has all organization headers intact. Organization headers all start with "X-MS-Exchange-Organization-". If this permission is not granted, the receiving server will strip all organization headers.
ms-Exch-Accept-Headers-Forest	This permission allows the session to submit a message that has all forest headers intact. Forest headers all start with "X-MS-Exchange-Forest-". If this permission is not granted, the receiving server will strip all forest headers.
ms-Exch-Accept-Exch50	This permission allows the session to submit a message that contains the XEXCH50 command. This command is needed for interoperability with Exchange 2000 and 2003. The XEXCH50 command provides data such as the spam confidence level (SCL) for the message.
ms-Exch-Bypass-Message-Size-Limit	This permission allows the session to submit a message that exceeds the message size restriction configured for the connector.
Ms-Exch-Bypass-Anti-Spam	This permission allows the session to bypass anti-spam filtering.

Local Network Settings

In the Exchange Management Console, 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 Exchange Management 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 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.

Note:
If you choose to bind a Receive connector to a specific local IP address, that IP address must be valid for the Hub Transport server or Edge Transport server on which the Receive connector is located. If you specify an invalid local IP address, the Microsoft Exchange Transport service may fail to start when the service is restarted. Instead of binding the Receive connector to a specific IP address, you can bind the Receive connector to all available IP addresses on the Hub Transport server or Edge Transport server.

Note:

If you choose to bind a Receive connector to a specific local IP address, that IP address must be valid for the Hub Transport server or Edge Transport server on which the Receive connector is located. If you specify an invalid local IP address, the Microsoft Exchange Transport service may fail to start when the service is restarted. Instead of binding the Receive connector to a specific IP address, you can bind the Receive connector to all available IP addresses on the Hub Transport server or Edge Transport server.

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 Exchange Management Console includes an option to Specify the FQDN this connector will provide in response to HELO or EHLO. In the Exchange Management 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 fully qualified domain name (FQDN) to the receiving server. In response, the receiving server sends a success code and provides its own FQDN. In Exchange 2007, you can customize the FQDN that is 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

Note:
Don’t modify the FQDN value on the default Receive connector named “Default <Server Name>” that is automatically created on Hub Transport servers. If you have multiple Hub Transport servers in your Exchange organization and you change the FQDN value on the “Default <Server Name>” Receive connector, internal mail flow between Hub Transport servers will fail.

Remote Network Settings

In the Exchange Management Console, 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 Exchange Management 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.

Note:
In Exchange 2007 Service Pack 1 (SP1), the IPv6 address range 0000:0000:0000:0000:0000:0000:0.0.0.0-ffff:ffff:ffff:ffff:ffff:ffff:255.255.255.255 also exists in the default Receive connectors on a Hub Transport server.

If you are 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

Note:
If Exchange Server 2007 SP1 is deployed on a computer that is running Windows Server 2008, you can enter IP addresses and IP address ranges in the IPv4 format, IPv6 format, or both formats. A default installation of Windows Server 2008 enables support for IPv4 and IPv6. For more information about Exchange 2007 SP1 support for IPv6 addresses, see IPv6 Support in Exchange 2007 SP1 and SP2.

Receive Connector Authentication Settings

In the Exchange Management Console, you use the authentication settings for a Receive connector to specify the authentication mechanisms that are supported by the Exchange 2007 transport server. In the Exchange Management Shell, you use the AuthMechanisms parameter to specify the supported authentication mechanisms. You can configure more than one authentication mechanism for a Receive connector. Refer to Table 2 earlier in this topic for the authentication mechanisms that are automatically configured for each usage type. Table 5 lists the available authentication mechanisms for a Receive connector.

Table 5 Receive connector authentication mechanisms

Authentication mechanism	Description
None	No authentication.
TLS	Advertise STARTTLS. Requires availability of a server certificate to offer TLS.
Integrated	NTLM and Kerberos (Integrated Windows authentication)
BasicAuth	Basic authentication. Requires an authenticated logon.
BasicAuthRequireTLS	Basic authentication over TLS. Requires a server certificate.
ExchangeServer	Exchange Server authentication (GSSAPI and Mutual GSSAPI).
ExternalAuthoritative	The connection is considered externally secured by using a security mechanism that is external to Exchange. The connection may be an Internet Protocol security (IPsec) association or a virtual private network (VPN). Alternatively, the servers may reside in a trusted physically controlled network. The `ExternalAuthoritative` authentication method requires the `ExchangeServers` permission group. This combination of authentication method and security group permits the resolution of anonymous sender e-mail addresses for messages that are received through this connector. This replaces the Resolve anonymous senders function in Exchange Server 2003.

Note:
We strongly recommend against configuring Receive connectors to accept anonymous connections from unknown IPv6 addresses. If you configure a Receive connector to accept anonymous connections from unknown IPv6 addresses, the amount of spam that enters your organization is likely to increase. Currently, there is no broadly accepted industry standard protocol for looking up IPv6 addresses. Most IP Block List providers do not support IPv6 addresses. Therefore, if you allow anonymous connections from unknown IPv6 addresses on a Receive connector, you increase the chance that spammers will bypass IP Block List providers and successfully deliver spam into your organization. For more information about Exchange 2007 SP1 support for IPv6 addresses, see IPv6 Support in Exchange 2007 SP1 and SP2.

Note:

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 Exchange Management Console. For more information about the properties that can be configured by using the Exchange Management Shell, see Set-ReceiveConnector.

For More Information

For more information, see the following topics: