Sdílet prostřednictvím


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

  • 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.

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.

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.

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: