How to Configure a Relay Connector in Exchange Server 2013
A very common scenario for Exchange Server 2013 administrators is the need to allow applications and devices on the network to use the Exchange server as an SMTP service.
There are generally two specific business requirements:
Internal SMTP relay – the ability to make an SMTP connection to an Exchange 2013 server and send email to recipients that are internal to the organization (for example, a “scan to email” feature on a multi-function print device)
External SMTP relay – the ability to make an SMTP connection to an Exchange 2013 server and send email to recipients that are outside the organization (for example, applications or hardware that sends automated reports or alerts to external vendors or consultants)
In this article I will demonstrate how to meet both of those requirements in Exchange Server 2013.
But first, let’s cover some of the fundamental Exchange 2013 concepts that apply here.
FRONTEND TRANSPORT VS TRANSPORT VS MAILBOX TRANSPORT
The Client Access server role hosts the Frontend Transport service, which provides filtering of email traffic (eg antispam agents), and routing of email between the internal Exchange servers and the outside world
The Mailbox server role hosts two additional services:
Transport service – performs email routing within the organization, and between the Front End transport service and the Mailbox Transport service
Mailbox Transport service – passes email messages between the Transport service and the mailbox database. This is actually two separate services, Mailbox Transport Submission and Mailbox Transport Delivery.
On a multi-role server this adds up to four services (Transport Log Search is not relevant to mail flow):
PS C:\> Get-Service | Where DisplayName -like "*Transport*" | Select DisplayName
DisplayName
-----------
Microsoft Exchange Frontend Transport
Microsoft Exchange Mailbox Transport Delivery
Microsoft Exchange Mailbox Transport Submission
Microsoft Exchange Transport
Microsoft Exchange Transport Log Search
On a Client Access server there is only one service.
PS C:\> Get-Service | Where DisplayName -like "*Transport*" | Select DisplayName
DisplayName
-----------
Microsoft Exchange Frontend Transport
No matter whether the server is multi-role or only installed with the Client Access server role, the Frontend Transport service is the only service already listening on TCP port 25 (SMTP). The other services listen on a variety of other ports (for example TCP 2525 for the Transport service).
For both internal and external SMTP relay scenarios the Frontend Transport service will be handling the connections. So whether you’ve deployed multi-role or CAS-only servers we’ll only be referring to the Client Access server role from now.
ALLOWING INTERNAL SMTP RELAY VIA THE FRONTEND TRANSPORT SERVICE
The Client Access server role is configured with a receive connector called “Default Frontend SERVERNAME” that is intended to be the internet-facing receive connector, so is already set up to receive SMTP connections from unauthenticated sources and allow them to send email to internal recipients.
220 E15MB1.exchange2013demo.com Microsoft ESMTP MAIL Service ready at Mon, 7 Oct
2013 23:49:54 +1000
helo
250 E15MB1.exchange2013demo.com Hello [192.168.0.181]
mail from: test@hotmail.com
250 2.1.0 Sender OK
rcpt to: administrator@exchange2013demo.com
250 2.1.5 Recipient OK
data
354 Start mail input; end with .
.
250 2.6.0 <df2bd0b4-08be-4b48-be83-c52e63721a4c@E15MB1.exchange2013demo.com> [In
ternalId=19911468384257] Queued mail for delivery
This means that the only additional (and optional) step for making internal SMTP relay available to your applications and devices is to provide a DNS name for them to connect to. You can just use the name of an Exchange 2013 server that is installed with the Client Access server role, or you can set up a more generic host record in DNS for them to use (which I recommend, as this makes it easier to migrate the service in future).
Adding a DNS alias for Exchange 2013 SMTP relay
ALLOWING EXTERNAL SMTP RELAY VIA THE FRONTEND TRANSPORT SERVICE
Although the default Frontend Transport receive connector allows internal SMTP relay it will not allow external SMTP relay. Here is an example of what happens if I use Telnet to try and send an email to an address that is external to the organization.
220 E15MB1.exchange2013demo.com Microsoft ESMTP MAIL Service ready at Tue, 8 Oct
2013 00:05:04 +1000
helo
250 E15MB1.exchange2013demo.com Hello [192.168.0.181]
mail from: administrator@exchange2013demo.com
250 2.1.0 Sender OK
rcpt to: exchangeserverpro@gmail.com
550 5.7.1 Unable to relay
To permit specific applications and devices to relay to external recipients we need to configure a new receive connector.
In the Exchange Admin Center navigate to Mail Flow -> Receive Connectors. Select the server that you wish to create the receive connector on. Remember, the server should be either a multi-role server or a Client Access server.
Click the + icon to create a new receive connector.
Give the new connector a name. Exchange names the various default connectors using a standard of “Purpose SERVERNAME”, for example “Client Frontend E15MB1”. So I tend to stick with that convention.
If the server you chose is multi-role you’ll need to select the Frontend Transport role. If the server is CAS-only then Frontend Transport will already be selected.
Leave the Type set to Custom, and then click Next.
For servers with a single network adapter the default binding will usually be fine.
For the remote network settings, click the – icon to remove the default IP address range. Then click the + icon and add at least one IP address of an application server or device that requires external SMTP relay access.
Click Finish to create the new receive connector.
Next we need to configure some additional settings for the receive connector. Highlight the connector and click the “pencil” icon to edit its settings. Select Security and tick theAnonymous Users box.
Click Save to apply the settings.
The final step involves granting anonymous users (such as the unauthenticated SMTP connections coming from applications and devices on your network) the ability to send to external recipients.
In the Exchange Management Shell run the following command, substituting the name of your receive connector.
As with the internal relay example I recommend creating a DNS record for a generic name for SMTP. For most environments there is no need to create separate DNS names for internal vs external SMTP.
Where previously the server responded with “550 5.7.1 Unable to relay”, now an SMTP connection from the IP address 192.168.0.181 is allowed to relay successfully.
220 E15MB1.exchange2013demo.com Microsoft ESMTP MAIL Service ready at Tue, 8 Oct
2013 21:11:04 +1000
helo
250 E15MB1.exchange2013demo.com Hello [192.168.0.181]
mail from: administrator@exchange2013demo.com
250 2.1.0 Sender OK
rcpt to: exchangeserverpro@gmail.com
250 2.1.5 Recipient OK
data
354 Start mail input; end with .
.
250 2.6.0 <3fe0353b-1e2a-4a6d-9e08-f7744621a0e1@E15MB1.exchange2013demo.com> [In
ternalId=20005957664769] Queued mail for delivery
HOW DOES EXCHANGE 2013 KNOW WHICH RECEIVE CONNECTOR TO USE?
You may be wondering how the server knows which receive connector should handle the incoming SMTP connection, considering that both the “Default Frontend E15MB1” and “Relay E15MB1” connectors are listening on all IP addresses and on the same port (TCP 25).
Simply put, receive connector selection is on a “most specific match wins” basis. The connector with remote network settings that most closely match the IP of the connecting server/device will be the one that handles the connection.
The “Default Frontend” receive connector has remote network settings equivalent to “anything”.
The “Relay” connector we just created has remote network settings that list specific IP addresses.
So, if two SMTP connections are inbound, one from 192.168.0.180 and the other from 192.168.0.181, the server knows to handle 192.168.0.181 with the “Relay” connector as it is the more specific match, and handle the other connection with the “Default Frontend” connector.
With the relay connector in place the ongoing management is simple.
If an application or device needs internal SMTP relay, simply configure it to use the DNS record you configured (eg smtp.exchange2013demo.com) and port 25.
If an application or device needs external SMTP relay, simply add the IP address of the application server or device to the remote network settings of the relay connector, and then configure the application or device to use the DNS record you configured.
No comments:
Post a Comment