Understanding Send Connectors
Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2
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
| Type | Default permissions | SID that's granted the default permissions | Default smart host authentication mechanism |
|---|---|---|---|
Custom |
None |
None |
None |
Internal |
|
|
Exchange Server Authentication |
Internet |
Ms-Exch-Send-Headers-Routing |
Anonymous User Account |
None |
Partner |
Ms-Exch-Send-Headers-Routing |
Partner Servers |
Not applicable. This usage type is selected when you establish mutual Transport Layer Security (TLS) authentication with a remote domain. |
Note
If Domain Name System (DNS) resolution delivery is selected for a Send connector instead of a smart host, no smart host authentication mechanism is configured.
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:
The following table lists common connection scenarios and the usage type for each scenario.
Connector usage scenarios
| Connector scenario | Usage type | Comment |
|---|---|---|
Edge Transport server that sends e-mail to the Internet |
Internet |
A Send connector that's configured to send e-mail to all domains is created automatically when the Edge Transport server is subscribed to the Exchange organization. |
Hub Transport server that sends e-mail to the Internet |
Internet |
This isn't a recommended configuration. |
A subscribed Edge Transport server that sends e-mail to a Hub Transport server |
Internal |
This connector is automatically created by the Edge Subscription process. |
Edge Transport server that sends e-mail to an Exchange 2003 bridgehead server |
Internal |
The Exchange 2003 bridgehead server is configured as a smart host for the Send connector. |
Edge Transport server that sends e-mail to a Hub Transport server |
Custom |
When the Edge Subscription process isn't used, a manual connector must be created. Use the Add-ADPermission cmdlet to set the extended rights. Set the authentication mechanism as Basic authentication or Externally Secured. |
Cross-forest Send connector for a Hub Transport server in one forest that sends e-mail to an Exchange 2010 or Exchange 2007 Hub Transport server in a second forest |
Custom |
For detailed configuration steps, see Configure Cross-Forest Connectors. |
Cross-forest Send connector for a Hub Transport server in one forest that sends e-mail to an Exchange 2003 bridgehead server in a second forest |
Custom |
For detailed configuration steps, see Configure Cross-Forest Connectors. |
Hub Transport server that sends e-mail to a third-party smart host |
Custom |
Use the Add-ADPermission cmdlet to set the extended rights. Route all messages to a smart host and set the authentication mechanism to either Basic authentication or Externally Secured. |
Edge Transport server that sends e-mail to a third-party smart host |
Custom |
Use the Add-ADPermission cmdlet to set the extended rights. Route all messages to a smart host and set the authentication mechanism to either Basic authentication or Externally Secured. |
Edge Transport server that sends e-mail to an external relay domain |
Custom |
The Edge Transport server can accept e-mail for an external relay domain and then relay the messages to the authoritative e-mail system for that domain. Route all messages to a smart host, set the appropriate authentication mechanism, and use the Add-ADPermission cmdlet to set the extended rights. |
Edge Transport server that sends e-mail to 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-SendConnector. |
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
| Send connector permission | Description |
|---|---|
ms-Exch-Send-Exch50 |
This permission allows the session to send a message that contains the EXCH50 command. If this permission isn't granted, and a message is sent that contains the EXCH50 command, the server sends the message, but doesn't include the EXCH50 command. |
Ms-Exch-Send-Headers-Routing |
This permission allows the session to send a message that has all received headers intact. If this permission isn't granted, the server removes all received headers. |
Ms-Exch-Send-Headers-Organization |
This permission allows the session to send a message that has all organization headers intact. Organization headers all start with X-MS-Exchange-Organization-. If this permission isn't granted, the sending server removes all organization headers. |
Ms-Exch-Send-Headers-Forest |
This permission allows the session to send a message that has all forest headers intact. Forest headers all start with X-MS-Exchange-Forest-. If this permission isn't granted, the sending server removes all forest headers. |
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.
Note
Although you can configure non-SMTP address spaces on a Send connector on a Hub Transport server, the Send connector uses SMTP as the transport mechanism to send messages to other messaging servers. Delivery Agent connectors and foreign connectors on Hub Transport servers are used to send messages to non-SMTP local messaging servers, such as third-party fax gateway servers. For more information, see Understanding Delivery Agents and Understanding Foreign Connectors.
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
| Address space entry | Send connector routes mail to: |
|---|---|
* |
All domains that don't have an explicit address space entry on another Send connector entry or that aren't an included subdomain of an address space on another Send connector. |
Contoso.com |
All recipients with e-mail addresses in the Contoso.com domain. |
*.Contoso.com |
All recipients with e-mail addresses in the Contoso.com domain or any subdomain of Contoso.com. In the EMC, select Include all subdomains to set this configuration. |
-- |
This address space is only used on Send connectors configured on Edge Transport servers for sending messages to the Hub Transport servers. When you use this address space, all messages addressed to your accepted domains are routed through this 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:
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
| Security setting | Description |
|---|---|
None |
Anonymous access is allowed. |
Basic authentication |
Basic authentication requires that you provide a user name and password. Basic authentication sends credentials in clear text. All smart hosts with which this Send connector is authenticating must accept the same user name and password. |
Basic authentication over TLS |
Select TLS to encrypt the transmission of the credentials. The receiving server must have a server certificate. The exact FQDN of the smart host, MX record, or A record that's defined on the Send connector as the smart host identity must also exist in the server certificate. The Send connector will attempt to establish the TLS session by sending the STARTTLS verb to the destination server and will only perform Basic authentication after the TLS session has been established. A client certificate is also required to support mutual TLS authentication. |
Exchange Server authentication |
Exchange Server authentication (Generic Security Services application programming interface (GSSAPI) and Mutual GSSAPI) |
Externally Secured (for example, with IPsec) |
The network connection is secured using a method that's external to the Exchange server. |
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:
New Features in Exchange 2010 Service Pack 1
In Service Pack 1 (SP1) for Exchange Server 2010, new functionality was added to Send connectors. This section provides an overview of these new features.
Support for Downgrading Connection Failures
You may have dedicated Send connectors that are responsible for transmitting messages over well-defined communication channels that are expected to always be available, such as a Send connector dedicated to send messages to Microsoft Office 365 or to one of your partners over a private channel. On such connections, many of the typical errors that are possible on ordinary destinations on the Internet aren't expected. In this scenario, you may want to treat any communication errors as transient as opposed to issuing non-delivery reports (NDRs). With Exchange 2010 SP1, you can configure a Send connector to downgrade authentication and name resolution errors, which would normally result in an NDR, to transient errors. In these cases, Exchange will attempt delivery again instead of issuing an NDR.
Downgrading connection failures over reliable connections give you an opportunity to troubleshoot and resolve problems without impacting your users.
Important
This feature should only be enabled for Send connectors that transmit messages over well-defined and reliable networks. You shouldn't enable this feature for your Send connectors to the Internet.
To configure this feature, you use the ErrorPolicies parameter of the Set-SendConnector cmdlet. You can choose to downgrade authentication failures, DNS failures or both for any Send connector. For more information about configuring this property, see Set-SendConnector.
Support for TLS Domain Validation
Exchange 2010 SP1 provides support for domain validation for outbound TLS connections. Domain validation is an additional security feature that reduces the risk of malicious users impersonating a receiving server. When you enable domain validation on a Send connector, the Transport server performs the following security checks on the outbound connection:
The communication channel is encrypted using TLS.
The certificate of the receiving server is validated and revocation list checks are performed.
The Transport server verifies that the FQDN on the certificate of the receiving server matches the domain configured in the Send connector properties.
When you enable domain validation on a Send connector, you also have to specify the domain name to validate against. Both of these properties are configurable using the TlsAuthLevel and TlsDomain parameters of the Set-SendConnector cmdlet. For more information about configuring this feature, see Set-SendConnector.
© 2010 Microsoft Corporation. All rights reserved.