This article is for:

• Exchange Server on-premises environments where external inbound SMTP is directly received by an Exchange Server
• IMAP and/or POP3 legacy clients are not being used externally that would need authenticated SMTP to relay messages to the Internet

The Issue: 

The “Default Frontend <servername>” receive connector is dual-purposed.  It handles internal server-to-server mail delivery (authenticated) and receives email from the internet on behalf of the domain. 

Since it is configured as authenticated, malicious actors can connect externally and provide credentials repeatedly in an attempt to either lockout valid users or to guess users’ network passwords to compromise Windows user accounts.

The Solution:  Adding an Internet Receive Connector and Adjusting the Default Receive Connector

Step one:

Apply a scope to the “Default Frontend <servername>” receive connector, so it can now service only internal connections, allowing Exchange to continue to transport messages server-to-server, and also allow internal clients / devices (e.g. printers) to authenticate if necessary to introduce e-mail messages.

Step two:

Create a new front-end receive connector specifically to accept anonymous SMTP connections.  This new receive connector will have the full IPv4 and IPv6 ranges.

NOTE: Although the receive connector will accept anonymous SMTP connections, it is “NOT” an open relay.  New receive connectors by default do not relay messages back to the Internet.  To configure a receive connector for relaying, a special set-adpermission command has to be run in order to configure relaying.  This new receive connector will only accept e-mail for delivery to the domains that are listed on the Accepted Domains list in EAC.

The Procedure:

Modify the existing “Default Frontend <servername>” receive connector to configure the ‘RemoteIPRanges’ to instruct the connector to only service internal connections.

The following ranges are internal (IPv4 and IPv6, CIDR notation):

• 172.160.0.0/12
• 10.0.0.0/8
• fec0::/10
• fc00::/7
• 192.168.0.0/16

These changes can be made in EAC on the “Default Frontend <servername>” receive connector, under ‘scoping’ as below:

We then need to create a new front-end receive connector specifically to accept anonymous SMTP connections.  This new receive connector will have the full IPv4 and IPv6 ranges.

We can create the new receive connector using EAC:

On the next screen, leave the full IPv4 range and add the full IPv6 range by clicking on the + sign.

Click on ‘Finish’.  

There are three critical pieces left to modify on this new receive connector:

• Security configuration (to only have anonymous)
• EHLO/HELO header (typically critical for proper mail flow)
• Applying a certificate to support STARTTLS command

On the security ‘tab’, ensure only Anonymous is checked, and that TLS is allowed.

On the ‘scoping’ tab, modify the FQDN to provide the banner name to match the expected value.  This should match the MX record for proper mail delivery.

Note that if the ‘banner’ attribute is configured in Exchange powershell, it will override this FQDN.

Apply a certificate to support the STARTTLS command.  If you are using a custom certificate, it is likely that the “Default Frontend <servername>” receive connector already has the certificate configured.

You can check to see the name of the TLS certificate being used, and set the same name on the new connector.  This can only be done using Exchange powershell commands.

get-receiveconnector | fl identity,*tls*

Identity              : HEX13\Default Frontend HEX13

TlsCertificateName    : <I>CN=Sectigo RSA Domain Validation Secure Server CA, O=Sectigo Limited, L=Salford, S=Greater Manchester, C=GB<S>CN=*****

If there is a TLS certificate, can copy the name, and then apply the name to the new connector.

get-receiveconnector -identity "<server>\Incoming Email from Internet (Anonymous SMTP)" | set-receiveconnector -TlsCertificateName "<I>CN=Sectigo RSA Domain Validation Secure Server CA, O=Sectigo Limited, L=Salford, S=Greater Manchester, C=GB<S>CN=*****"

Verification – using MX Toolbox

Use a tool like MX Toolbox to check that the incoming SMTP looks properly configured.  Alternatively, directly telnet to the mail server from an external computer.

Go to the mxtoolbox.com website, enter your SMTP domain (e.g. company.com) and click on the ‘MX Lookup’ button.

On the next screen, note now that there is an arrow dropdown on the button with additional choices.

Type in the mail server’s external name (i.e. should match the MX record) into the textbox, and select ‘Test Email Server’ from the drop-down, and then click on the button ‘Test Email Server’.

Scroll down to review the protocol sequence, to see what authentication options are listed.

Verification – using telnet

Telnet to the mail server from an external computer over port 25

telnet <mailserver> 25

Type in ‘ehlo company.com’ – this will spur the mail server to provide extended information on its capabilities.  In the response, see what authentication options are listed.

Appendix A: Ports to allow/block (externally)

By default, firewalls should be blocking all ports except those specifically allowed. 

The following port(s) should be allowed:

• SMTP port 25

The following ports should typically be blocked:

• POP3 ports 110, 995
• IMAP ports 143, 993
• SMTP port 717 (internal port used when hub transport connects to ‘cas’ for outbound e-mail)
• SMTP port 465 (internal port used by hub transport, also this is for SMTP over SSL which was never official and now is depreciated)
• SMTP port 587 (client submission port for POP3/IMAP to submit messages to an SMTP server)
• SMTP port 2525 (internal port used by hub transport as an alternative client submission port)

Note: If POP3 and IMAP legacy protocols are not in use, these Exchange Services should also be disabled on the Exchange Server.