Receive Connectors
Microsoft Exchange Server 2007 will reach end of support on April 11, 2017. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.
Applies to: Exchange Server 2007, Exchange Server 2007 SP1, Exchange Server 2007 SP2, Exchange Server 2007 SP3
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.
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 |
|
ExchangeUsers |
Authenticated user accounts |
|
ExchangeServers |
|
|
ExchangeLegacyServers |
Exchange Legacy Interop security group |
|
Partner |
Partner Server account |
|
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:
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 |
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 |
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.
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 serverDuring 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 |
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.
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: