Send Connectors: Exchange 2007 Help

Send Connectors

Applies to: Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007 Topic Last Modified: 2007-07-10

Send connectors are configured on computers that are running Microsoft Exchange Server 2007 and that have Hub Transport and Edge Transport server roles 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 2007 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 directory service 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 the following topics:

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. In Active Directory, a Send connector is created as an object in a connector's container. If a Send connector is configured to send messages to an external domain, when any Hub Transport server in the organization routes a message to that domain, the message is delivered to a source server for that connector for relay to the destination domain.

The Send connector that is used to route messages to a recipient is selected during the routing resolution phase of message categorization. For more information, see Understanding Active Directory Site-Based Routing.

Selecting the Usage Type for a Send Connector

When you use the Exchange Management Console 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 is not required. If you don't specify a usage type when you run the New-SendConnector cmdlet, the default usage type is set to Custom. Table 1 describes the Send connector usage types and their default settings.

Table 1 Send connector usage types

Type	Default permissions	SID that is granted the default permissions	Default smart host authentication mechanism
Custom	None	None	None
Internal	ms-Exch-Send-Headers-Organization ms-Exch-SMTP-Send-Exch50 ms-Exch-Send-Headers-Routing ms-Exch-Send-Headers-Forest	Hub Transport servers Edge Transport servers Exchange Servers (on Hub Transport only) Externally secured servers Exchange Legacy Interop universal security group Exchange Server 2003 and Exchange 2000 Server bridgehead servers	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:
In some scenarios, domain name system (DNS) MX record resolution is used to route messages instead of relaying them through a smart host. If DNS resolution is selected for a Send connector, no authentication mechanism is configured.

The Send connector permissions and smart host authentication mechanisms are discussed 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:

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

Table 2 Connector usage scenarios

Connector scenario	Usage type	Comment
Edge Transport server that sends e-mail to the Internet	Internet	A Send connector that is 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 is not a recommended configuration. For more information, see How to Configure Connectors for Internet Mail Flow.
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 Server 2003 or Exchange 2000 Server bridgehead server	Internal	The Exchange 2003 or Exchange 2000 bridgehead server is configured as a smart host for the Send connector.
Hub Transport server that sends e-mail to a Hub Transport server	Internal	You do not have to configure Send connectors between Hub Transport servers within the same organization. This usage type can be used to configure a cross-forest Send connector.
Hub Transport server that sends e-mail to 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 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 that sends e-mail to a Hub Transport server	Custom	When the Edge Subscription process is not 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 a Hub Transport server in a second forest	Custom	For detailed configuration steps, see Configuring Cross-Forest Connectors.
Cross-forest Send connector for a Hub Transport server in one forest that sends e-mail to 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 that sends e-mail to a third-party message transfer agent	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 message transfer agent	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: The value of the DomainSecureEnabled parameter must be `$True`. The value of the DNSRoutingEnabled parameter must be `$True`. The value of the IgnoreStartTLS parameter must be `$False`. 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 is not allowed by the Send connector permissions, those headers are stripped from the message when it is sent. Table 3 describes the permissions that can be assigned on a Send connector to security principals. You can't set Send connector permissions by using the Exchange Management Console. To modify the default permissions for a Send connector, you must use the Add-AdPermission cmdlet in the Exchange Management Shell.

Table 3 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 is not 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 is not 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 is not 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 is not 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. Foreign connectors on Hub Transport servers are used to send messages to local messaging servers, such as third-party fax gateway servers, which don't use SMTP as their primary transport mechanism. For more information, see Foreign Connectors.

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. Foreign connectors on Hub Transport servers are used to send messages to local messaging servers, such as third-party fax gateway servers, which don't use SMTP as their primary transport mechanism. For more information, see Foreign Connectors.

Table 4 lists valid entries for the SMTP address space of a Send connector.

Table 4 Valid entries for the SMTP address space of a Send connector

Address space entry	Send connector routes mail to:
*	All domains that do not have an explicit address space entry on another Send connector entry or that are not 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 Exchange Management Console, select Include all subdomains to set this configuration.

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 is configured to use the *.Contoso.com address space. When you configure a Send connector for a particular address space, e-mail that is 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 is only usable by other Hub Transport servers that exist in the same Active Directory site.

Address Spaces and Connector Scope in Exchange 2007 RTM

In the release to manufacturing (RTM) version of Exchange 2007, the complete syntax for specifying an address space is as follows:

<ConnectorScope>:<AddressSpaceType>:<AddressSpace>;<AddressSpaceCost>

The elements of the address space are described in the following list:

ConnectorScope If you specify a value of Local, the connector can only be used by other Hub Transport servers in the same Active Directory site. If you omit the ConnectorScope qualifier, the connector can be used by all Hub Transport servers in the Exchange 2007 organization.
AddressSpaceType The address space type may be SMTP, X400, or any other text string. If you omit the address space type, an SMTP address space type is assumed.
AddressSpace For SMTP address space types, the address space that you enter must be RFC 1035-compliant. For example, *, *.com, and *.contoso.com are permitted, but *contoso.com is not permitted. For X.400 address space types, the address space that you enter must be RFC 1685-compliant, such as o=MySite;p=MyOrg;a=adatum;c=us. For all other values of address type, you can enter any text for the address space.
AddressSpaceCost The valid input range for the cost is 1 to 100. A lower cost indicates a better route. If you omit the address space cost, a cost of 1 is assumed. If you enter a non-SMTP address space that contains the semicolon character ( ; ), you must specify the address space cost.

If you specify the connector scope, the address space type, or the address space cost, you must enclose the address space in double quotation marks ( " ). For example, the following address space entries are equivalent:

"SMTP:contoso.com;1"
"contoso.com;1"
"SMTP:contoso.com"
contoso.com

You may specify multiple address spaces by separating the address spaces with commas, as follows, for example: contoso.com,fabrikam.com. If you specify the connector scope, the address space type, or the address space cost, you must enclose the address space in double quotation marks ( " ) as follows, for example: "contoso.com;2","Local:fabrikam.com;3".

Address Spaces and Connector Scope in Exchange 2007 SP1

In Microsoft Exchange Server 2007 Service Pack 1 (SP1), the address space syntax is slightly different from the address space syntax of Exchange 2007 RTM. In Exchange 2007 SP1, the complete syntax for specifying an address space is as follows:

<AddressSpaceType>:<AddressSpace>;<AddressSpaceCost>

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

In the Exchange Management Console, use the Scoped Send connector property in the Address Space page in 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 is not selected, the connector can be used by all Hub Transport servers in the Exchange organization.
In the Exchange Management 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 Domain Name System (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 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 is 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 Exchange Management Console to modify the DNS settings on the Exchange server properties. You can also use the Exchange Management 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 Exchange Management 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, a mail exchange (MX) record, or an address (A) 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.

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

The smart host for a Send connector with the Internet usage type may be a server that is 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 cannot be set to require TLS.

Table 5 lists the smart host authentication mechanism that you can configure for a Send connector.

Table 5 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 is defined on the Send connector as the smart host identity must also exist in the server certificate. The Send connector will try STARTTLS 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 (GSSAPI and Mutual GSSAPI)
Externally secured (for example, with IPsec)	The network connection is secured using a method that is 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 is 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 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-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 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 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 is 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

Note:
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 is not used. Instead, the FQDN of the server that is 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

Note:

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 is not used. Instead, the FQDN of the server that is 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 Exchange Management Console. For more information about the properties that can be configured by using the Exchange Management Shell, see Set-SendConnector. These additional Send connector properties include settings for the protocol logging level, and linked Receive connectors. When a Send connector is linked to a Receive connector, all messages that are received through that Receive connector are delivered by using the Send connector to which it is linked.

For More Information

For more information, see the following topics: