3. Using and Configuring Send Connectors
Send connectors are configured on Hub
Transport or Edge Transport servers. The Send connector on a Transport server
represents a logical gateway through which outbound messages are sent to the
next hop on the way to their destination. No explicit Send connectors are
created by default when the Hub Transport or Edge Transport server role is
installed. However, implicit and invisible Send connectors are automatically
computed based on the site topology and are used to route messages internally
between Hub Transport servers.
End-to-end mail flow requires that Edge Transport servers be subscribed to the
Active Directory site by using the Edge subscription process. If your
organization has an Internet-facing Hub Transport server or an unsubscribed Edge
Transport server, you need to manually configure Send connectors to establish
end-to-end mail flow.
A Send connector created on a Hub Transport server is stored in Active
Directory and is 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 routes a message for that domain to a
source server for that connector. The message is then relayed to the destination
domain.
3.1. Send Connector Usage Type
You can use the New Send Connector Wizard in the EMC or an EMS command
based on the New-SendConnector cmdlet to create a Send
connector. When you use the EMC, you need to specify a usage type for the
connector. When you use the EMS, the default usage type is set to
Custom.
The usage type determines the default permissions that are assigned on the
connector and grants those permissions to trusted security principals, such
as users, computers, and security groups. A security principal is identified
by a security identifier. The usage type also defines the default smart host
authentication mechanism. Note that if DNS resolution delivery is selected
for a Send connector instead of a smart host, no smart host authentication
mechanism is configured. Send connector permissions and smart host
authentication mechanisms are discussed in detail later in this lesson. The
available usage types are as follows:
Custom
This usage type has no default permissions and no smart host
authentication mechanism. You would select the Custom usage type
for a Send connector on an unsubscribed Edge Transport server
that sends email to a Hub Transport server. You would also
select the Custom usage type for a cross-forest Send connector
on a Hub Transport server that sends email to an Exchange Server
2010 or an Exchange Server 2007 Hub Transport server, or to an
Exchange Server 2003 bridgehead server in a second forest. You
would also select this usage type for a Send connector on a Hub
Transport server that sends email to a third-party smart host
and for an Edge Transport server that sends email to a
third-party smart host or to an external relay domain.
Internal
The default permission
sets for this usage type are ms-Exch-Send-Headers-Organization,
ms-Exch-SMTP-Send-Exch50, ms-Exch-Send-Headers-Routing, and
ms-Exch-Send-Headers-Forest. Default permissions are granted to
Hub and Edge Transport servers, externally secured servers, the
Exchange Legacy Interop universal security group, and Exchange
Server 2003 and Exchange 2000 Server bridgehead servers. The
Default smart host authentication mechanism is Exchange Server
Authentication. You would select this usage type for a Send
connector on a subscribed Edge Transport server that sends email
to a Hub Transport server or to an Exchange 2003 bridgehead
server. This connector is automatically created by the edge
subscription process, and if email is being sent to an Exchange
2003 bridgehead server, that server needs to be configured as a
smart host.
Internet
The default permissions set for this usage type is
Ms-Exch-Send-Headers-Routing. Default permissions are granted to
anonymous user accounts and there is no smart host
authentication mechanism. You would select this usage type for a
Send connector on an Edge Transport server that sends email to
the Internet. Note that a Send connector that is configured to
send email to all domains is created automatically when the Edge
Transport server is subscribed to the Exchange organization. If
you wanted to send email directly on to the Internet from a Hub
Transport server, you would need to configure a Send connector
with the Internet usage type. However, this is not considered
best practice.
Partner
The default permissions set for this usage type is
Ms-Exch-Send-Headers-Routing, and default permissions are
granted to partner servers. The smart host authentication
mechanism is not applicable because this usage type is selected
when you establish MTLS authentication with a remote domain. You
would apply the Partner usage type to a Send connector on an
Edge Transport server that sends email to a domain with which
you have established MTLS authentication.
3.2. Send Connector Address Space
The Send connector address space, specified, for example, in the
AddressSpace parameter of the New-SendConnector EMS
cmdlet, specifies the names of domains to which the Send connector routes
mail. You need to specify the AddressSpace parameter unless the Send
connector you are creating is linked to a Receive connector. If a linked
Receive connector is specified by using the LinkedReceiveConnector
parameter, the value of the AddressSpace parameter must be $null. Receive
connectors are discussed later in this lesson.
Note:
THE ADDRESSSPACE PARAMETER
You can use AddressSpace or AddressSpaces interchangeably with the
New-SendConnector cmdlet. Both parameters
specify one or more address spaces.
The syntax for entering an address space is as follows:
<AddressSpaceType>:<AddressSpace>;<AddressSpaceCost>
Note:
Notice that the first symbol in the
address space syntax is a colon and that the second is a
semicolon.
On an Edge Transport server, the address space type must be SMTP. On a Hub
Transport server, it may be SMTP, X400, or another text string. If you omit
the address space type, SMTP is assumed.
For SMTP address space types, the address space that you enter must be RFC
1035 compliant, for example, *.*.com, and *.adatum.com. For X.400 address
space types, the address space that you enter must be RFC 1685 compliant,
such as o=ThisSite;p=ThisOrg; a=adatum;c=us. For all other values of address
space type, there are no format restrictions on the text for the address
space.
The valid input range for the address space cost is from 1 through 100. A
lower cost indicates a better route. This parameter is optional; 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 address space type or the address space cost, you must
enclose the address space in quotation marks (“), for example,
“SMTP:adatum.com;1.”
You can specify multiple address spaces by separating the address spaces
with commas, for example, contoso.com,fabrikam.com or
“SMTP:adatum.com;1”,“SMTP:Fabrikam.com;2”.
Note:
NON-SMTP ADDRESS SPACE
If you specify a non-SMTP address space type on a Send connector
configured on a Hub Transport server, you must use a smart host to route
email by specifying a value for the SmartHosts parameter, and you must
set the DNSRoutingEnabled parameter to $false.
The following EMS command creates a Send connector named SendConnector01
with a usage type of Internet that sends email to all .com Internet
sites:
New-SendConnector -Internet -Name SendConnector01 -AddressSpace "SMTP:*.com;1"
Figure 4 shows the output of this
command.
The following EMS command reconfigures the Send connector SendConnector01
to send email to an address space of the adatum.com domain and all its
subdomains:
Set-SendConnector -Identity SendConnector01 -AddressSpace *.adatum.com
Note:
CHANGING THE USAGE TYPE
You cannot reconfigure the usage type using the
Set-SendConnector cmdlet. To do this, you need
to delete the connector using the
Remove-SendConnector cmdlet and then re-create
it with a different usage type. You can (optionally) use the Usage
parameter in the New-Send-Connector cmdlet to
specify the usage type for a new Send connector, but this parameter does
not exist for the Set-SendConnector cmdlet.
The following EMS command lists the properties of the Send connector
SendConnector01:
Get-SendConnector -Identity SendConnector01
Figure 5 shows the output
of this command.
Note:
DISABLING OR REMOVING A SEND
CONNECTOR
If you want to temporarily disable a Send connector, you would use the
Set-SendConnector EMS cmdlet and set the
Enabled parameter to $false. If you use the Remove-SendConnector
parameter, this deletes the Send connector, and you would subsequently
need to create it again.
3.3. Send Connector Permissions
When a security principal establishes a session with a Send connector, the
Send connector permissions assigned to that security principal determine the
types of header information that can be sent with the email message. If an
email message includes header information that is not allowed by the Send
connector permissions, those headers are stripped from the message. Table 2 describes the permissions
that can be assigned on a Send connector to security principals. You can use
the Add-ADPermission EMS cmdlet to modify the default
permissions for a Send connector.
Table 2. Send Connector Permissions
|
Send Connector Permission
|
Description
|
|---|
|
ms-Exch-Send-Exch50
|
Allows the session to send a message that contains the
EXCH50 command.
|
|
Ms-Exch-Send-Headers-Routing
|
Allows the session to send a message that has all
received headers intact.
|
|
Ms-Exch-Send-Headers-Organization
|
Allows the session to send a message that has all
organization headers intact.
|
|
Ms-Exch-Send-Headers-Forest
|
Allows the session to send a message that has all
forest headers intact.
|
3.4. Send Connector Scope
You can use the scope of a Send connector to control the visibility of the
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 usable only by other Hub Transport servers in the same Active
Directory site.
You can use the EMS IsScopedConnector parameter in the
New-SendConnector cmdlet or the
Set-SendConnector cmdlet. When the value of this
parameter is $true, the connector can be used only 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.
For example, the following EMS command configures the Send connector
SendConnector01 so that it can be used only by Hub Transport servers in the
same Active Directory site:
Set-SendConnector -Identity SendConnector01 -IsScopedConnector $true
3.5. Using DNS Resolution to Deliver Email
You can configure Send connectors so that they deliver email by using DNS
address resolution or by routing the email to a smart host. When the Send
connector is set to use DNS Mail Exchange (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 is configured on
the source server’s internal network adapter is used for name
resolution.
You can configure a specific DNS server to use internal and external DNS
lookups by using the EMC to modify the DNS settings on the Exchange server
properties. If you configure a DNS on the Transport server to use external
DNS lookups and use the New SMTP Send Connector wizard in the EMC to create
a Send connector, you can select Use DomainName System (DNS)
“MX” Records To Route Mail Automatically on the Network Settings
page of the wizard. Whether you select this option or the alternative Route
Mail Through The Following Smart Hosts, you can choose to select the Use The
External DNS Lookup Settings On The Transport Server check box.
You can configure a Send connector to use DNS resolution by setting the
UseExternalDNSServersEnabled parameter with the
Set-SendConnector or
New-SendConnector EMS cmdlets. When this parameter
is set to $true (the default is $false), the Send
connector uses the external DNS list that you can specify by using the
Set-TransportServer EMS cmdlet with the
ExternalDNSServers parameter, such as follows:
Set-TransportServer -Identity VAN-EX1 -ExternalDNSServers 192.168.30.2,10.10.50.10
Set-SendConnector -Identity SendConnector01 -UseExternalDNSServersEnabled $true
3.6. Using a Smart Host to Route Email
You must specify a smart host if you select the Internal usage type for a
Send connector. When you route mail through a smart host, this 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 Address (A) resource record. If you
configure an FQDN as the smart host identity, the source server for the Send
connector uses DNS name resolution to locate the smart host server.
If you specify the Internet usage type for a Send connector, the smart
host for that connector 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 email server in your organization or an
email server in a remote domain.
The following EMS command creates a Send connector named Contoso that
transmits messages through a smart host named smarthost.contoso.com to
Contoso’s mail domain mail.contoso.com (note that the usage type is
Internet and that you would create such a connector on an Edge Transport
server):
New-SendConnector -Internet -Name Contoso -Addresspaces smtp:mail.contoso.com
-Smarthosts smarthost.contoso.com
When you route mail through a smart host, you must specify how the source
server will authenticate to the smart host computer. You cannot require
security settings for a Send connector unless a smart host destination is
specified.
Table 3 lists the smart
host authentication mechanisms that you can configure for a Send
connector.
Table 3. Smart Host Authentication Mechanisms
|
Security Setting
|
Description
|
|---|
|
None
|
Anonymous access is allowed.
|
|
Basic authentication
|
This requires 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
|
TLS encrypts 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 performs Basic authentication only after
the TLS session has been established. A client
certificate is also required to support MTLS
authentication.
|
|
Exchange Server authentication
|
This uses 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
is external to the Exchange 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. When you specify more than one source
server, this provides 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.
3.7. Configuring Maximum Message Size and Connection Inactivity
Time-Out
You can configure the maximum size of messages sent through a Send
connector. Take care to distinguish this from the maximum message size sent
over an IP site link. By no means do all the messages that are sent through
a Send connector pass over an IP site link. If a message is subject to both
Send connector and site-link restrictions, the smaller of the two maximum
message sizes is enforced.
You can use the MaxMessageSize parameter with both the
New-SendConnector and the
Set-SendConnector EMS cmdlets to specify maximum
message size. The default value is 10 MB. To remove the message size limit
on a Send connector, you can enter a value of unlimited.
You can also use the ConnectionInactivityTimeOut parameter with both the
New-SendConnector and the
Set-SendConnector EMS cmdlets to specify the
maximum time that an idle connection can remain open. The default value is
10 minutes. To specify a value, you enter it as a time span in the format
dd.hh:mm:ss, where d = days, h = hours, m =
minutes, and s = seconds. The valid input range for this parameter is from
00:00:01 through 1.00:00:00.
The following command configures the send connector SendConnector01 with a
maximum message size of 5 MB and a maximum time for which an idle connection
can remain open for 20 minutes:
Set-SendConnector -Identity SendConnector01 -MaxMessageSize 5MB
-ConnectionInactivityTimeOut 00:20:00
