Managing Relay in Exchange Server 2013 (Part 2)

by [Published on 21 Jan. 2016 / Last Updated on 21 Jan. 2016]

Configuring Exchange Server to support e-mail relay for several type of applications/network devices.

If you would like to be notified of when Anderson Patricio releases the next part in this article series please sign up to our MSExchange.org Real Time Article Update newsletter.

If you would like to read the first part in this article series please go to Managing Relay in Exchange Server 2013 (Part 1).

Introduction

In the first article, we went over the key components to configure the relay in your organization, covering the basics on security and DNS.

In this second part, we are going to configure Exchange Server 2013 for the changes The same concept can be applied to previous versions (Exchange Server 2007/2010) and the upcoming version which is the Exchange Server 2016.

Network Adapters

The first step is to add/configure an additional adapter on Exchange Server to handle relay traffic.

The reason behind this is simple, all traffic related to relay will be managed on that interface and we will be able to control it easily. Additional hardware nowadays is not a big issue, most on-premises physical servers have more than one adapter and Virtual Servers have the ability to have additional adapters without additional cost.

The first step is to add the additional adapter, after that rename it to RELAY, and then hit ALT button, click on Advanced, and finally on Advanced Settings. Make sure that the network adapter connected on the network with Active Directory is the primary. The network adapter for relay is below that one, as shown in Figure 01.

Image
Figure 01

The second step is to disable all clients and services on the relay adapter and leave only IPv4 and IPv6 (Figure 02). After that configure the static IP on the adapter (since we already defined the IP as 10.60.99.205 on the DNS entry created on the first article, we will assign the same IP on that adapter for logical reasons).

Image
Figure 02

The final step on the network side is to uncheck the option Register this connection’s addresses in DNS, as shown in Figure 03.

Image
Figure 03

Relay Receive Connector

We have all the settings on the back end to support relay (DNS and network adapters), however we haven’t configured Exchange for that new demand. The first step is to create a receive connector that can be used by any internal device user to send messages internally only.

  1. Open Exchange Admin Center
  2. Click on Mail Flow, and then Receive Connectors
  3. Click on + and type in the name of the connector (RELAY in this Article), select Frontend Transport, and select Custom (for example, to allow application relay), and click Next (Figure 04)

Image
Figure 04

  1. In the new page, click on Edit and define the IP address of the relay adapter which is 10.60.99.205 in this article, and click next (Figure 05)

Image
Figure 05

  1. In the new page, leave default settings (which is 0.0.0.0-255.255.255.255) and click finish

After that we need to perform some changes. Let’s double-click on the receive connector that was just created, and on the security tab, we will deselect Transport Layer Security (TLS), and we will select Basic authentication. On the Permission groups sections the options Anonymous users and Exchange Users should be selected, as shown in Figure 06.

Image
Figure 06

In the scoping tab, we will type Relay.patricio.ca and that piece of information will be helpful during the troubleshooting process because that name is displayed when the client connects on the Receive Connector using a telnet session (Figure 07).

Image
Figure 07

Time to test the new Receive Connector. We will use telnet client from any computer or even from the Exchange Server to test it. All commands used to test are listed below and the results can be seen on Figure 08. In the test we are trying to simulate a real scenario, where the e-mail scanner@patricio.ca will be sending a message to another mailbox within the exchange organization.

telnet relay.apatricio.ca 25 <enter>

ehlo patricio.ca<enter>

mail from:scanner@patricio.ca<enter>

rcpt to:administrator@patricio.ca<enter>

data<enter>

Subject : Subject Test 01<enter>

<enter>

<enter>

Message body.

. <enter>

Quit<enter>

Image
Figure 08

In the previous test we were able to send a message to a local mailbox. If we try to perform a similar test but this time sending to an external recipient, we will get the error 5.7.1 Unable to relay as shown in the figure 09.

Image
Figure 09

During the configuration we selected Exchange users on the permission groups of the receive connector, and also Basic Authentication. For that reason we can configure any client to use authentication to send messages through that same connector and when that happens besides of local messages, the external messages are also accepted.

This exercise of using an authenticated user to send messages to both local and external destinations can be seen in Figure 10 where both messages were accepted by the Exchange Server. In this exercise we are using Eudora client to authenticate on Exchange Server.

Image
Figure 10

Using this scenario, the administrator can guarantee that the same relay.patricio.ca can be used for regular applications and devices that do not require authentication and for services/applications that need to send messages to external recipients using authentication. The recommendation here is to create a service account on Active Directory and use those credentials to authenticate.

Using Default Domain feature…

Since this new Receive Connector will be used for all internal messages, we can see that a printer/scanner which users use to scan documents and send to their e-mails will be using this type of connector.

By default, if we try to send a message using just the username, it will fail (Figure 11, A), however if we define the parameter DefaultDomain at the Receive Connector level (Figure 11, B), then we can use just usernames (Figure 11, C).

Why is that important? Well, using such feature we can save a lot of time for end users by not having to go to a scanner and having to type just the username instead of the entire SMTP address.

Set-ReceiveConnector <Name> -DefaultDomain Patricio.ca

Image
Figure 11

Managing Exceptions...

In some scenarios, an application may require to send messages to external addresses without authentication (usually legacy applications). If that is the case the recommendation is to create another connector using the same IP address from the previous relay connector, but on that new connector. Make sure to configure the remote network settings to list only the servers that are part of that exception (last page of the wizard).

In the past, we tried to relay an external message without authentication and we got the error 5.7.1 Unable to relay, as shown in Figure 12.

Image
Figure 12

By default, an anonymous logon will not have access to send messages to external recipient, and in order to allow that, the following cmdlet can be used (Figure 13).

Get-ReceiveConnector <Relay-Exception> | Add-ADPermission –User “NT Authority\Anonymous Logon” –ExtendedRights “ms-Exch-SMTP-Accept-Any-Recipient”

Image
Figure 13

Conclusion

At the end of this article we have a new host relay.patricio.ca which can be used by printer devices and any other application without authentication to send messages internally. The same connector can receive authenticated connections and for those the messages can be relayed to external recipients.

When the existent server has to be removed from the environment, the administrator just needs to point out the relay.patricio.ca to the new server which can be another server running Exchange Server 2013, or a brand new version running Exchange Server 2016.

If you would like to be notified of when Anderson Patricio releases the next part in this article series please sign up to our MSExchange.org Real Time Article Update newsletter.

If you would like to read the first part in this article series please go to Managing Relay in Exchange Server 2013 (Part 1).

See Also


The Author — Anderson Patricio

Anderson Patricio avatar

Anderson Patricio is a consultant for Microsoft technologies. He works with Exchange Server, ISA Sever and Active Directory deployments at a Microsoft Gold Partner in Toronto, Canada. In the Technet Brasil community, he contributes news, articles and webcasts.

Advertisement

Featured Links