Tag Archives: Receive Connector

Exchange 2016 and Exchange 2019 SMTP Relay

The last couple of days I have been working with multiple customers on SMTP relay in Exchange 2016 during a migration from Exchange 2010 to Exchange 2016. The last time I did that was with Exchange 2010, almost 9 years ago https://jaapwesselius.com/2012/05/25/smtp-relay-in-exchange-2010/ and things have changed over the years. The changes in Exchange 2016 are carried forward in Exchange 2019…. Oh, and this is true for Exchange 2013 as well, but since Exchange 2013 is already out of support and none of my customers is using Exchange 2013 I’ll skip this….

Exchange 2010 has the Hub Transport service for SMTP, and this is using port 25 for communicating with other SMTP hosts. Exchange 2016 and Exchange 2019 have two services for SMTP transport:

  • Front-End Transport service (FETS) listening on port 25. This is where other SMTP hosts connect to. In the Exchange 2016 Admin Center the FETS Receive Connector is identified as Default Frontend <server> . In Exchange 2013, this service was running on the Client Access Server.
  • Hub Transport Service listening on port 2525. This is a back-end service used by FETS and other Exchange Hub Transport back-end services. Clients are not expected to use the Hub Transport service on port 2525. In the Exchange Admin Center this Receive Connector is identified as Default <server> . In Exchange 2013, this service was running on the Mailbox server.

These connectors are shown in the following screenshot. The Default Frontend Receive Connector (on port 25) is selected, the red arrow points to the Hub Transport Receive Connector on port 2525.

Note. The Client Frontend Receive Connector in the screenshot is listening on port 587 and is used for authenticated SMTP clients like Mozilla Thunderbird.

SMTP Relay in Exchange 2016 and 2019

The Default Frontend Receive Connector allows all SMTP clients to connect to it and drop email messages for local delivery. You don’t want to configure this connector to relay SMTP message to external domains, this is known as an ‘open relay’ and this is the number one reason to be put on every blacklist available on the Internet. You can do this and restrict access based on IP addresses, but I strongly recommend against changing the default connectors. Leave the inbound SMTP traffic end up on the Default Frontend Receive Connector and create a dedicated connector for SMTP relay traffic.

There are two ways to create such a relay connector:

  • Create a dedicated receive connector (on Frontend Transport, not on Transport Service), restrict by IP address and add the Ms-Exch-SMTP-Accept-Any-Recipient permission on the NT AUTHORITY\ANONYMOUS LOGON security principal. This is what I have shown in the blog mentioned earlier, and this is only possible using Exchange PowerShell. Sending hosts are considered anonymous, and anti-spam and message size limits are applied.
  • Create a dedicated receive connector (again on the Frontend Transport), restrict by IP address, and add the Exchange Servers and Externally Secured authentication mechanism to the connector. In this scenario, sending hosts are considered as authenticated senders, and email messages bypass anti-spam and message size limits. And it’s easy to configure using the Exchange Admin Console.

Since the first option is already documented, I will continue with the second option. Personally, I like to do this with PowerShell and the command to create such a connector and configure it are like these:

[PS] C:\>New-ReceiveConnector -Name "SMTP Relay EXCH01" 
-Server EXCH01 -TransportRole FrontendTransport -Custom 
-Bindings 0.0.0.0:25 -RemoteIpRanges 10.38.96.15

Identity                 Bindings     Enabled
--------                 --------     -------
EXCH01\SMTP Relay EXCH01 {0.0.0.0:25} True


[PS] C:\>Set-ReceiveConnector "EXCH01\SMTP Relay EXCH01" 
-AuthMechanism ExternalAuthoritative 
-PermissionGroups ExchangeServers

[PS] C:\>

When you check the connector using the Exchange Admin Center, you can see that the authentication mechanism is set correctly as shown in the following screenshot:

It is also possible to create a new connector using the Exchange Admin Center. In the EAC, navigate to mail flow and select the receive connectors tab and click the + icon. Follow the wizard, give the new connector a proper name, select Frontend Transport and Custom, and restrict by IP address as shown in the following screenshots:

When created, open the new receive connector, select security and configure the authentication mechanmism to Externally secured and Exchange servers as shown in a previous screenshot.

It is now possible to relay SMTP messages from the server with IP address 10.38.96.15. Using Telnet on port 25, you will see something like this:

When trying to relay from another server (which is not listed in the Remote Network Settings) it will fail with the 550 5.7.54 SMTP; Unable to relay recipient in non-accepted domain error as shown in the following screenshot:

Summary

So in short, do not configure the default receive connector in such a way that it will relay messages outside of the Exchange server. When you need to use SMTP relay, create a dedicated connector.

The first and most secure option is to create a new receive connector, restrict by IP address and configure the Ms-Exch-SMTP-Accept-Any-Recipient permission. Anti-spam and message size limits are applied, but it can only be configured using PowerShell (and thus more complex).

The second on is to create a new receive connector, restrict by IP address and configure the authentication mechanisms. Easier to configure (using EAC) but less secure: anti-spam and message limits are not applied.

It is up to you which one to use.

Exchange 2010 hybrid, SMTP, SSL Certificates and Subject Alternative Names

On every Exchange server you need SSL certificates for authentication, validation and encryption purposes. For SMTP you can use the self-signed certificate. Exchange 2010 uses opportunistic TLS, so the self-signed certificate will do in this scenario. If you need to configure domain security (mutual TLS) on Exchange, you need a proper 3rd party SSL certificate for this.

SMTP communication between Office 365 and Exchange in a hybrid scenario is an example of mutual TLS or domain security. A proper 3rd party SSL certificate is needed on your Exchange server.

I was always under the impression that mutual TLS can only use the Common Name of the certificate, which in my scenario is CN=webmail.inframan.nl. After a previous blogpost there was an interesting discussion (see the comments of this particular blogpost) about this, so now it’s time to do some testing.

Originally I had a Digicert SSL certificate with Common Name CN=webmail.inframan.nl, and a Subject Alternative Name entry autodiscover.webmail.com. During the HCW I entered webmail.inframan.nl and selected the proper certificate.

It was time to renew my SSL certificate, so I added an additional SAN entry o365mail.inframan.nl.

image

Continue reading Exchange 2010 hybrid, SMTP, SSL Certificates and Subject Alternative Names

Exchange 2010 Hybrid cannot establish Mutual TLS wrong certificate is used

When configuring an Exchange 2010 hybrid environment a Receive Connector is created on the Exchange 2010 server. This Receive Connector is configured with the FQDN entered in the Hybrid Configuration Wizard (see previous blog post on Exchange 2010 Hybrid) and the source IP addresses of the Microsoft Exchange Online servers. If one of these servers access the Exchange 2010 environment, they end up on the Office 365 Receive Connector (based on the IP address) and the correct SSL certificate is returned. This way mutual TLS is established between Exchange 2010 on-premises and Exchange Online.

It sometimes happens that the wrong certificate is used for SMTP communication between Exchange on-premises and Exchange Online, thus resulting in SMTP mail flow failure between the two.

You can check this in the Exchange Admin Center (EAC) in Exchange Online. Logon to the EAC in Exchange Online, select Mail Flow and click the Connectors tab. You’ll see two connectors. One connector for mail from Exchange 2010 to Exchange Online, and one connector for mail from Exchange Online to Exchange 2010.

image

Continue reading Exchange 2010 Hybrid cannot establish Mutual TLS wrong certificate is used

Upgrade to CU8 Fails on Receive Connector misconfiguration

During an upgrade of an Exchange 2013 SP1 multi-role server to Exchange 2013 CU8 the upgrade crashed, apparantly on a strange Receive Connector configuration since the following error message was raised:
The values that you specified for the Bindings and RemoteIPRanges parameters conflict with the settings on Receive connector ” SERVER1\Relay Connector SERVER1″. Receive connectors assigned to different Transport roles on a single server must listen on unique local IP address & port bindings.

image

Continue reading Upgrade to CU8 Fails on Receive Connector misconfiguration