Understanding Send Connectors

Applies to: Exchange Server 2010

Send 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. The Send Connector represents a logical gateway through which outbound messages are sent. This topic provides an overview of Send connectors and explains how the configuration of Send connectors affects the processing of individual messages.

Overview of Send Connectors

Exchange 2010 transport servers require Send connectors to deliver messages to the next hop on the way to their destination. A Send connector controls outbound connections from the sending server to the receiving server or destination e-mail system. By default, no explicit Send connectors are created when the Hub Transport server role or the Edge Transport server role is installed. However, implicit and invisible Send connectors that are automatically computed based on the Active Directory site topology are used to route messages internally between Hub Transport servers. End-to-end mail flow is only possible 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 configuration of connectors to establish end-to-end mail flow. For more information, see Transport Server Post-Deployment Tasks.

Send connectors that are created on Hub Transport servers are stored in Active Directory and are available to all Hub Transport servers in the organization. If a Send connector is configured to send messages to an external domain, any Hub Transport server in the organization will route a message for that domain to a source server for that connector to be relayed to the destination domain.

The Send connector that's used to route messages to a recipient is selected during the routing resolution phase of message categorization. For more information, see Understanding Message Routing.

Selecting the Usage Type for a Send Connector

When you use the Exchange Management Console (EMC) to create a Send connector, the New SMTP Send Connector wizard prompts you to select a usage type for the connector. The usage type determines the default permission sets that are assigned on the connector and grants those permissions to trusted security principals. Security principals include users, computers, and security groups. A security principal is identified by a security identifier (SID).

You can also specify a usage type when you create a Send connector by using the New-SendConnector cmdlet in the Exchange Management Shell. However, the Usage parameter isn't required. If you don't specify a usage type when you run the New-SendConnector cmdlet, the default usage type is set to Custom. The following table describes the Send connector usage types and their default settings.

Send connector usage types

The Send connector permissions and smart host authentication mechanisms are discussed in detail later in this topic.

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

Connector usage scenarios

Send Connector Permissions

You assign Send connector permissions to a security principal. When a security principal establishes a session with a Send connector, the Send connector permissions determine the types of header information that can be sent with the e-mail message. If an e-mail message includes header information that isn't allowed by the Send connector permissions, those headers are stripped from the message when it's sent. The following table describes the permissions that can be assigned on a Send connector to security principals. You can't set Send connector permissions by using the EMC. To modify the default permissions for a Send connector, you must use the Add-ADPermission cmdlet in the Shell.

Send connector permissions

Address Spaces and Connector Scope

The address space for a Send connector specifies the recipient domains to which the Send connector will route e-mail. You can specify SMTP address spaces or non-SMTP address spaces on Send connectors that are configured on Hub Transport servers. You can only specify SMTP address spaces on Send connectors that are configured on Edge Transport servers. If you use a non-SMTP address space type, you must use a smart host to route e-mail.

The following table lists valid entries for the SMTP address space of a Send connector.

Valid entries for the SMTP address space of a Send connector

During routing resolution, a Send connector, to which e-mail is routed for delivery to the destination address space, is selected. The Send connector whose address space most closely matches the recipient's e-mail address is selected. For example, an e-mail message addressed to Recipient@marketing.contoso.com would be routed through the connector that's configured to use the *.Contoso.com address space. When you configure a Send connector for a particular address space, e-mail sent to that address space is always routed through that connector. Also, the configuration settings for that connector are always applied to e-mail sent to that address space.

You can use the scope of a Send connector to control the visibility of the Send connector within the Exchange organization. By default, all Send connectors that you create are usable by all the Hub Transport servers in the Exchange organization. However, you can limit the scope of any Send connector so that it's only usable by other Hub Transport servers that exist in the same Active Directory site.

In Exchange 2010, the complete syntax for specifying an address space is as follows:

<AddressSpaceType>:<AddressSpace>;<AddressSpaceCost>

You can use the following methods to specify the scope of the Send connector:

• In the EMC, use the Scoped Send connector property in the Address Space page of the New SMTP Send Connector wizard, or in the Address Space tab in the properties of an existing Send connector.
  When Scoped Send connector is selected, the connector can only be used by Hub Transport servers in the same Active Directory site. When Scoped Send connector isn't selected, the connector can be used by all Hub Transport servers in the Exchange organization.
• In the Shell, use the IsScopedConnector parameter in the New-SendConnector cmdlet or the Set-SendConnector cmdlet.
  When the value of this parameter is $true, the connector can only be used by Hub Transport servers in the same Active Directory site. When the value of this parameter is $false, the connector can be used by all Hub Transport servers in the Exchange organization.

Network Settings

You can set Send connectors so that they deliver e-mail by using DNS address resolution or by routing the e-mail to a smart host.

Using DNS to Route E-Mail

When the Send connector is set to use DNS MX resource records to route mail automatically, the DNS client on the source server must be able to resolve public DNS records. By default, the DNS server that's configured on the source server's internal network adapter is used for name resolution. You can configure a specific DNS server to use for internal and external DNS lookups by using the EMC to modify the DNS settings on the Exchange server properties. You can also use the Shell to configure the parameters in the Set-TransportServer cmdlet.

If you configure a specific DNS server on the transport server to use for external DNS lookups, you must select Use the external DNS lookup settings on the transport server on the Network Settings page of the New SMTP Send Connector wizard or, in the Shell, on the Set-TransportServer cmdlet, set the UseExternalDNSServersEnabled parameter to $true. The DnsRoutingEnabled parameter on the Send connector must also be set to $true.

For more information, see the following topics:

• Configure Edge Transport Server Properties
• Configure Hub Transport Server Properties
• Set-TransportServer

Using a Smart Host to Route E-Mail

If you select the Internal usage type for the Send connector, you must specify a smart host. When you route mail through a smart host, the smart host handles delivery to the next hop in the delivery destination. You can use an IP address or the fully qualified domain name (FQDN) of the smart host to specify the smart host identity. The smart host identity can be the FQDN of a smart host server, an MX record, or an A (address) resource record. If you configure an FQDN as the smart host identity, the source server for the Send connector must be able to use DNS name resolution to locate the smart host server.

The smart host for a Send connector with the Internet usage type may be a server that's hosted by your Internet service provider. The smart host for a Send Connector with the Custom or Internal usage types may be another e-mail server in your organization or an e-mail server in a remote domain.

Smart Host Security Settings

When you route mail through a smart host, you must specify how the source server will authenticate to the smart host computer. You can't require security settings for a Send connector unless a smart host destination is specified. For example, an Internet-facing connector can't be set to require TLS.

The following table lists the smart host authentication mechanism that you can configure for a Send connector.

Smart host authentication mechanisms

Source Server

You must select at least one source server for a Send connector. The source server is the transport server to which messages are routed for delivery through the selected Send connector. You can set more than one source server on a Send connector that's configured for the Exchange organization. When you specify more than one source server, you provide load balancing and redundancy if a server fails. The source servers associated with Send connectors that are configured for the Exchange organization can be Hub Transport servers or subscribed Edge Transport servers.

FQDN

The General tab of the Send connector properties in the EMC includes the option 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-SendConnector 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 sending server if you configure this property on a Send connector. The value of the Fqdn parameter is displayed to connected messaging servers whenever a source server name is required, as in the following examples:

• In the most recent Received: header field of the message that's added to the message by the next hop messaging server after the message leaves the Hub Transport server or Edge Transport server
• During TLS authentication

If the Send connector is configured on a Hub Transport server that also has the Mailbox server role installed, any value that you specify for the Fqdn parameter isn't used. Instead, the FQDN of the server that's displayed by using the Get-ExchangeServer cmdlet is always used.

For servers that have both the Hub Transport server role and the Mailbox server role installed, the only way to remove the server name from the Received: headers of the outgoing message is to use the Remove-ADPermission cmdlet to remove the Ms-Exch-Send-Headers-Routing permission from the security principals that use the connector. This action will remove all the Received: headers from the message as the message leaves the Hub Transport server. We recommend that you don't remove the Received: headers for internal messages, because the Received: headers are used for maximum hop count calculations. For more information about the Remove-ADPermission cmdlet and the Get-ExchangeServer cmdlet, see the following topics:

• Remove-ADPermission
• Get-ExchangeServer

Additional Send Connector Properties

The property configuration for a Send connector defines how mail is sent through that connector. Not all properties are configurable in the EMC. For more information about the properties that can be configured by using the Shell, see Set-SendConnector.