4. Using and Configuring Receive Connectors
Exchange Server 2010 Hub Transport and Edge Transport servers use Receive
connectors to receive messages from the Internet, from email clients, and from
other email servers. A Receive connector controls inbound connections to your
Exchange organization. The Receive connectors you require on a Hub Transport
server for internal mail flow are, by default, automatically created when the
Hub Transport server role is installed. A Receive connector that can receive
email from the Internet (and from Hub Transport servers) is automatically
created when the Edge Transport server role is installed. End-to-end mail flow
can be implemented by subscribing an Edge Transport server to your Active
Directory site by using the Edge subscription process. Other scenarios, such as
an unsubscribed Edge Transport server, require manual connector configuration to
establish end-to-end mail flow.
In Exchange Server 2010, the Receive connector listens for inbound connections
that match its settings, such as connections that are received through a
particular local IP address and port or 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 specifying a larger message size, more recipients
per message, or more inbound connections.
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, it is stored in Active Directory as a child object of
the server on which it is created. When you create a Receive connector on an
Edge Transport server, it is stored in AD LDS on that server.
If you need additional Receive connectors for specific scenarios, you can
create them by using the EMS. Each Receive connector uses a unique
combination of IP address bindings, port number assignment, and remote IP
address ranges from which mail will be accepted by this connector.
4.1. Default Receive Connectors Created During Setup
When you install the Hub Transport server role, two Receive connectors are
created. Typically, additional Receive connectors are not required, and in
most cases the default Receive connectors do not require reconfiguration
change. You can, however, amend default Receive connector
settings or create additional Receive connectors if you consider it
appropriate to do so.
The default Receive connectors created when the Hub Transport server role
is installed are named Client <servername> and Default
<servername>, for example, Client VAN-EX1 and Default VAN-EX1. The
Client <servername> Receive connector accepts SMTP connections from
all non–Messaging Application Programming Interface (MAPI) clients,
such as POP and IMAP. The configuration of the Client <servername>
Receive connector is as follows:
Status: Enabled.
Protocol logging level: None.
Connector FQDN:
Servername.forestroot.extension (for
example, VAN-EX1.adatum.com).
Bindings: All available IP addresses. The server accepts mail
received through any network adapter on the Hub Transport
server.
Port: 587. This is the default port for receiving messages from
all non-MAPI clients for SMTP relay.
Remote server IP address range: 0.0.0.0 through 255.255.255.255
for IPv4 and 0000:0000:0000:0000:0000:0000:0.0.0.0 through
ffff:ffff:ffff:ffff:ffff:ffff:255.255.255.255 for IPv6. The Hub
Transport server accepts mail from any IP address.
Available authentication methods: TLS, Basic authentication,
Exchange Server authentication, Integrated Windows
authentication.
Permission groups: Exchange users.
The Default <servername> Receive connector accepts connections from
other Hub Transport servers and any Edge Transport servers in your
organization. The configuration of the Default <servername> Receive
connector is as follows:
Status: Enabled.
Protocol logging level: None.
Connector FQDN:
Servername.forestroot.extension
Local server Receive connector bindings: All available IP
addresses. The server accepts mail received through any network
adapter on the Hub Transport server.
Port: 25.
Remote server IP address range: 0.0.0.0 through 255.255.255.255
for IPv4 and 0000:0000:0000:0000:0000:0000:0.0.0.0 through
ffff:ffff:ffff:ffff:ffff:ffff:255.255.255.255 for IPv6. The Hub
Transport server accepts mail from any IP address.
Available authentication methods: TLS, Basic authentication,
Integrated Windows authentication.
Permission groups: Exchange users, Exchange servers, Legacy
Exchange servers.
During installation of the Edge Transport server role, one Receive
connector is created. This is configured to accept SMTP communications from
all IP address ranges and is bound to all
IP addresses on the local server. It is configured to have the Internet
usage type and accepts anonymous connections. Typically, no additional
Receive connectors are required on an Edge Transport server. If you use
EdgeSync, you do not need to make any configuration changes because the Edge
subscription process automatically configures permissions and authentication
mechanisms. Anonymous sessions and authenticated sessions are granted
different permission sets.
You can list all the Receive connectors configured on Hub Transport
servers in your Exchange organization by entering the following EMS command
on a Hub Transport server (the same command entered on an Edge Transport
server lists all the Receive connectors configured on that server):
Get-ReceiveConnector
Figure 6 shows the output from this
command entered on the VAN-EX1 Hub Transport server. This lists the two
connectors created by default when this server was added to the Hub
Transport role. The other Receive connectors listed were created during
experimentation and are unlikely to be configured on your test
network.
4.2. Receive Connector Usage Types
As with Send connectors, the usage type of a Receive connector determines
the default security settings for that connector and hence specifies the
permissions that are granted to sessions that connect to that connector and
the supported authentication mechanisms.
When you use the New-ReceiveConnector EMS cmdlet to
create a Receive connector, you can specify the usage type by using the
Usage parameter or by specifying the usage type directly with the
appropriate parameter switch, such as Custom.
The valid Receive connector usage types are Client, Custom, Internal,
Internet, and Partner. You need to supply a value for the Bindings parameter
if you specify the Internet, Partner, or Custom usage type. You need to
supply a value for the RemoteIPRanges parameter if you specify the
Client, Internal, Partner, or Custom usage type. If you do not specify a
value for a required parameter, the command ends unsuccessfully and does not
prompt you for the missing required parameters.
You would configure the Internet usage type for a Receive connector on an
Edge Transport server that is receiving email from the Internet. If a Hub
Transport server was Internet facing, you would also specify this usage
type; however, Internet-facing Hub Transport servers are not
recommended.
You would configure the Internal usage type for a Receive connector on a
Hub Transport server that is receiving email from a Hub Transport server in
another forest (you can also use the Custom usage type for cross-forest
connections), from a message transfer agent (MTA), or from an Exchange
Server 2003 bridgehead server in the same forest (in which case a routing
group must also exist). You would also configure this usage type on an Edge
Transport server that is receiving email from a Hub Transport server or from
an Exchange Server 2003 bridgehead server that is configured to use the Edge
Transport server as a smart host.
A Receive connector with the Client usage type is automatically created on
every Hub Transport server when the role is installed. By default, this
Receive connector is configured to receive email through TCP port
587.
You would configure the Custom usage type for a Receive connector on a Hub
Transport server receiving email from a Hub Transport server or an Exchange
Server 2003 bridgehead server in another forest. You would also configure
this usage type for a Receive connector on an Edge Transport server
receiving email from a third-party MTA, an external relay domain, or an
Exchange Hosted Services server.
You would configure the Partner usage type for a Receive connector on a
Hub Transport server receiving email from a domain with which you have
established MTLS authentication.
4.3. Creating and Configuring a Receive Connector
If you need to create and configure Receive connectors for specific
purposes, you can use commands based on the
New-ReceiveConnector and
Set-ReceiveConnector EMS cmdlets.
For example, the following command creates the Receive connector
ReceiveConnector01 with the Custom usage type; this connector listens for
incoming SMTP connections on the IP address 10.10.10.1 and port 25 and
accepts incoming SMTP connections only from the IP range 192.168.8.1 through
192.168.8.127:
New-ReceiveConnector -Name ReceiveConnector01 -Usage Custom -Bindings 10.10.10.1:25
-RemoteIPRanges 192.168.8.1-192.168.8.127
Note that the Bindings parameter specifies the local Hub or Edge Transport
server IP address and the port through which the Receive connector accepts
connections. These settings bind the Receive connector to a particular
network adapter and TCP port on the Hub or Edge Transport server. By
default, a Receive connector is configured to use all available network
adapters and TCP port 25. If the server on which it is created has multiple
network adapters, you may want the Receive connector to be bound to a
particular network adapter or to accept connections through an alternative
port. For example, you may want to configure one Receive
connector on an Edge Transport server to accept anonymous connections
through an external network adapter and to configure a second Receive
connector on the server to accept connections only from local Hub Transport
servers through the internal network adapter.
The IP address or IP address range for the remote servers from which a
Receive connector will accept inbound connections, as specified by the
RemoteIPRanges parameter, can use one of the following formats:
IP address
For example, 192.168.20.1
IP address range
For example, 192.168.20.10-192.16820.20
IP address with subnet
mask
For example, 192.168.20.0(255.255.255.0)
IP address with Classless Interdomain
Routing notation subnet mask
For example, 192.168.1.0/24
The following EMS command sets the authentication mechanism of the Receive
connector ReceiveConnector01 to Integrated Windows authentication:
Set-ReceiveConnector -Identity ReceiveConnector01 -AuthMechanism Integrated
The usage type you specify for a Receive connector defines its default
authentication method, but you can use the
Set-ReceiveConnector EMS cmdlet with the
AuthMechanism parameter as in the previous command to configure one of the
following mechanisms:
None
TLS
Integrated
BasicAuth
BasicAuthRequireTLS
ExchangeServer
ExternalAuthoritative
Typically, you create and configure additional Receive connectors in order
to specify a maximum message size, a connection time-out, or a connection
activity time-out for traffic from specified IP addresses where these
settings are different from those specified by default Receive connectors.
The following EMS command specifies a maximum message size of 100 MB, a
connection time-out of 20 minutes, and a connection inactivity time-out of
15 minutes for the ReceiveConnector01 Receive connector (note that the
connection time-out must be greater than the connection inactivity
time-out):
Set-ReceiveConnector -Identity ReceiveConnector01 -MaxMessageSize 100MB
-ConnectionTimeout 00:20:00 -ConnectionInactivityTimeout 00:15:00
When you have made significant configuration changes to a Receive
connector, it is a good idea to list these configuration changes and check
for errors. The following command displays the configuration changes made on
the Receive connector ReceiveConnector01:
Get-ReceiveConnector -Identity ReceiveConnector01 | FL Identity,AuthMechanism,Bindings,
ConnectionTimeout,ConnectionInactivityTimeout,MaxMessageSize
Figure 7 shows the output
from this command.
Finally, if you no longer need a Receive connector, you can delete
it—note that this is not the same as temporarily disabling it. The
following command deletes the Receive connector ReceiveConnector01:
Remove-ReceiveConnector -Identity ReceiveConnector01
4.4. Using a Receive Connector to Restrict Anonymous Relay
Anonymous relay on Internet SMTP messaging servers is a serious security
risk that could be (and probably will be) exploited by unsolicited
commercial email senders to hide the source of their messages. Therefore,
you need to place restrictions on Internet-facing messaging servers to
prevent relaying to unauthorized destinations.
In Exchange Server 2010, you typically tackle this problem by configuring
accepted domains on Edge Transport server or Hub Transport servers. Accepted
domains can be authoritative, internal relay, and external relay.
In Exchange Server 2010, an accepted SMTP domain is considered
authoritative when the Exchange organization hosts mailboxes for recipients
in this domain. The Edge Transport servers should always accept email that
is addressed to any of the organization’s authoritative domains. By
default, when the first Hub Transport server role is installed, one accepted
domain is configured as authoritative for the Exchange organization. The
default accepted domain is the FQDN for your forest root domain. If your
internal domain name differs from the external domain name, you must create
an accepted domain to match your external domain name. No accepted domains
are configured by default on Edge Transport servers.
When an Edge Transport server receives email from the Internet and the
recipient of the message is not part of an authoritative domain, the sending
server attempts to relay the message through the Exchange server. When a
server acts as a relay server that has no restrictions, this can put a large
burden on Internet-connected servers. You can prevent this open relay
scenario by rejecting all email that is not addressed to a recipient in your
organization’s authoritative domains. However, there are scenarios in
which an organization wants to let partners or subsidiaries relay email
through their Exchange servers. In Exchange Server 2010, you can configure
accepted domains as relay domains. Your organization receives the email
messages and then relays the messages to another email server.
You can configure a relay domain as an internal relay domain or as an
external relay domain. When you configure an internal relay domain, some or
all of the recipients in this domain do not have mailboxes in your Exchange
organization. Email from the Internet is relayed for this domain through
your Hub Transport servers. To support this scenario, you need to create an
accepted domain that is configured as an internal relay domain. The accepted
domain that is configured as an internal relay domain first tries to deliver
to a recipient in the Exchange organization. If the recipient is not found,
the message is routed to the Send connector that has the closest address
space match.
When you configure an external relay domain, messages are relayed by an
Edge Transport server to an email server that is outside the Exchange
organization and outside the organization’s network perimeter. In this
scenario, the MX resource record for the external relay domain references a
public IP address for the Exchange Server 2010 organization that is relaying
messages. The Edge Transport server receives the messages for recipients in
the external relay domain and then routes the messages to the email system
for the external relay domain. You need to configure a Send connector from
the Edge Transport server to the external relay domain. The external relay
domain may also use your organization’s Edge Transport server as a
smart host for outgoing mail.
You can also restrict anonymous relay by examining the source of incoming
messages. This method can be useful when an unauthenticated application or
messaging server uses a Hub Transport server or an Edge Transport server as
a relay server. When you create a Receive connector that is configured to
relay email traffic, you should implement the following restrictions:
For local network settings, restrict the Receive connector to
listen only on the appropriate network adapter on the Hub Transport
or Edge Transport server.
For remote network settings, restrict the Receive connector so
that it accepts connections only from a specified server or servers.
This restriction is necessary because this Receive connector is
configured to accept relay from anonymous users. Restricting the
source servers by IP address is the only measure of protection
possible on this Receive connector.
