Skip to content

Exchange On-Premises – authentication and mail relay

In the following article, I would like to review the subject Exchange on-Premise server, mail relay, authentication and an anonymous session (un-authenticated session). The main reason for writing this article is to try to clarify some of the miss concepts and the confusing terms that used regarding this subject.

Exchange Server authentication and mail relay

The term mail relay or relaying mail seems to be a common term when relating to mail infrastructure, but this term has a couple of meanings and different variations.

Another example could be the subject of Exchange On-Premises server and the need for authentication. The prevailing view is that each element that communicates or addresses Exchange server needs to identify himself to be able to complete the mail flow session, but this “idea” is right only for a particular scenario.

Q1: Does each host who address the Exchange server must identify?

A1: In general, the answers depend on the particular scenario and the “service” that the client/host need from Exchange server

  • An exchange mail client that needs to access their mailbox must be identified (provide user credentials).
  • Hosts, such as other mail servers who need to deliver an email message to one of the Exchange clients (recipient) doesn’t need to identify them self.
  • Hosts who address Exchange server asking him to deliver an email message to the external recipient (mail relay) need to identify them self (provide user credentials).

To be able to understand better the concept of authentication and Exchange base environment, we will need to understand the different elements that communicate Exchange server the different scenarios and the different characters in each of the different scenarios.

Exchange on-Premises vs. Exchange Online

The o365info website is dedicated primarily to Office 365 and Exchange Online based environment. The specific article relates to Exchange On-Premises based environment.

Despite the fact that the Exchange Online based on the “Exchange server technology” there are many implementation Differences between the Exchange On-Premises environment vs. the “cloud” environment.

Long short – most of the examples and the screenshot are relevant, mainly to the Exchange On-Premise environment.

The purpose of the article was to provide more information about a scenario of mix environment that consists of Exchange On-Premises environment and Exchange Online environment.

Who are the “elements” that communicate with the Exchange-based server?

The answer to this question could also be quite complicated because there are many types of “entities” that can communicate with the Exchange server and each one of them has a unique character and behaviors.

Let’s start with a very high-level classification: client vs. server.

1. Mail client

When we use the term “mail client” most of the time, we relate to Exchange clients that their mailbox is hosted on the Exchange server and this “mail client” address Exchange server asking him one of the following services:

  • Access to his data stored in the Exchange mailbox.
  • Deliver E-mail message to other mail recipients.

The term “mail client”, can be translated to a mail client that has an Exchange mailbox, and he needs to access his data stored in his mailbox.

Another type of mail client could be a device or an application that doesn’t have an Exchange mailbox and instead, relate to Exchange as a “mail server” asking him to “deliver” E-mail message to some recipient.

Another classification that we can use the term “mail client” is the type of the particular mail client.
Exchange server supports a broad range of the mail client. Each mail client, use a different mail protocol and different authentication protocols.

2. Mail Server

When we use the term “mail server” we mean to relate to another mail server that addresses the Exchange server.

The entities that communicate with Exchange based server - General classification -01

If we want to get a more accurate description, there could be an additional classification of the terms: mail client and mail server.

For example:

Regarding the term “mail server”, this definition can be translated to – “additional Exchange server” that is part of the Exchange organization.

“Exchange server” has a special relationship with an additional Exchange server from his organization.

Many of the configuration settings that relate to the communication process between Exchange server from the same organization such as the authentication protocol and access permissions configured automatically.

Many times, the term “mail server” relates to any “external mail server” that addresses the Exchange server asking him to “accept” E-mail message for one of the recipients who hosted on the Exchange server.

The entities that communicate with Exchange-based server - Different type of clients-02

Mail communication protocols

Regarding the subject of – the mail communication protocols in Exchange based environment, we will continue to use a basic classification of the mail client vs. mail server.

Mail server communication protocol

Regarding mail server that communicates with Exchange server, the most common communication protocol is the SMTP protocol.

In some scenario, the communication protocol that will used is TLS, which uses for encrypting the communication channel between the two endpoints (Exchange server and the other mail server).

Mail communication protocols - Mail server -03

Client Mail communication protocols

Regarding the term “mail client” I will classify a mail client to two main groups:

1. Standard Exchange mail client

This group includes all the familiar mail client such as Outlook, OWA, and mobile clients.
OWA and Outlook mail client use the HTTPS protocol for communicating with the Exchange mail server, and mobile mail client uses the ActiveSync protocol for communicating with Exchange mail server.

Regarding Outlook mail clients, if we want to be more accurate, Outlook mail client uses a combination of mail protocol such as RPC over HTTPS or MAPI over HTTPS, but for simplicity, we can say that OWA and Outlook mail client using the HTTPS protocol is the mail communication protocol.

Mail communication protocols -Standard mail client -04

2. Special or non-standard Exchange mail clients

Under this clarification, I put the mail client which I describe “Internet mail clients”.

This term, relate to old mail clients, that use the common internet protocol that was very popular in the past, for communicating with the Exchange-based server.

The internet mail client uses – POP3 and IMAP4 for retrieving E-mail message from the mailbox and SMTP for “sending out” E-mail message via the Exchange server.

Exchange server can support this type of mail client, but in most of the scenarios such as Exchange on-Premise environment or “cloud-based Exchange environment” (Office 365 and Exchange Online) this protocol is not used or not supported.

Mail communication protocols - internet mail clients -05

The “entity” that communicates with Exchange server and the requested type of service

1. Exchange mail client and Exchange server

Let’s start with the relationship that exists between Exchange clients and Exchange Server:
Exchange client “consume” from Exchange server two primary services:

1. Access to mailbox data

Exchange client that has Exchange mailbox connect Exchange server, provide the required credentials and ask from Exchange to access their data that located in the Exchange mailbox.

Exchange mail clients and the services that Exchange server provides - Access to mailbox -06

2. Addressing Exchange server for delivering email messages

The second common service that Exchange client “consume” from Exchange server is – the service in which the Exchange client address Exchange server and “ask” him to deliver an E-mail message to the other Exchange recipient or the external (non-Exchange recipient) recipient.

Exchange mail clients -services Exchange server provides - Deliver E-mail message -07

2. “Other” client and Exchange server

I use the term “another mail client” for describing any entity or hosts, who address the Exchange server and ask him to deliver an email message to some “destination recipient.”

This “another mail client” doesn’t have an Exchange mailbox.

This mail client could be – web-based application, mail-enabled devices such as a printer or scanner or any other than consume mail services.

The scenario in which an “element” address the Exchange server asking him to deliver an email message to a particular recipient can be implemented via authenticated session or non-authenticated (anonymous) session:

  1. Anonymous – a method in which the “element” that addresses Exchange server doesn’t provide any user credentials or in other words, doesn’t authenticate.
  2. Authentication by providing user credentials – a method in which the “element” that addresses Exchange server provides user credentials.
  3. Authentication based on IP address – in this method the “element” that addresses Exchange server doesn’t provide any user credentials but instead uses a specific IP address that was already.
The entities that communicate with Exchange based server -Other mail clients -08

3. Mail servers and Exchange server

When I use the term “mail server”, I refer to external mail servers who represent an external domain (a domain which is not managed by Exchange) that address Exchange server is asking him to deliver or forward an E-mail message to a particular recipient who is hosted by the Exchange.

The entities that communicate with Exchange-based server - External mail servers -09

The “entity” that communicates with the Exchange-based server and the authentication protocol

In this section, we will continue to use the classification of the different “entities” that communicate with the Exchange server, but this time, I would like to focus on the subject of the authentication infrastructure.

Exchange mail client and Exchange server

When relating to Exchange client, the need for the “authentication” is a mandatory requirement.

Exchange client that addresses Exchange server, asking for any type of services, need to provide first his credentials and, only the credentials are verified, Exchange will “agree” to provide a specific service such as access to mailbox data or delivering an E-mail message.

Each of the different Exchange clients such as Outlook, OWA or mobile client (ActiveSync) uses a different authentication protocol and the protocol has a specific character.

Exchange server and the authentication requirements from Exchange clients -01
In the following section, I provide a quick review for the different authentication setting that can be configured for the different type of Exchange clients.

OWA mail client

In the following screenshot, we can see the different authentication setting that can be configured for OWA mail clients.
OWA mail client can use authentication method such as:

  • Integrated Windows authentication
  • Basic authentication
  • Digest authentication
  • Formed based authentication
Exchange server and the authentication requirements from Exchange clients -02

ActiveSync mail client

In the following screenshot, we can see the different authentication setting that can be configured for ActiveSync mail clients.
ActiveSync mail client can use authentication method such as:

  • Basic authentication
  • Client side certificate
Exchange server and the authentication requirements from Exchange clients -03

IMAP4\POP3 mail client

In the following screenshot, we can see the different authentication setting that can be configured for IMAP4\POP3 mail clients.
IMAP4\POP3 mail client can use authentication method such as:

  • Clear text
  • Clear text over TLS
Exchange server and the authentication requirements from Exchange clients -04

Outlook (MAPI) mail client

In the following screenshot, we can see the different authentication setting that can configure for Outlook mail clients.

Outlook (MAPI) mail client, can use authentication method such as:

  • Basic authentication
  • NTLM authentication
Exchange server and the authentication requirements from Exchange clients -05

Internet mail client, “Other” mail client, Mail servers, and Exchange server

In the previous section, we review the “Interface” that is used by Exchange clients for communicating with the Exchange server.

In the current section, I would like to review the “other Exchange communication interface” that serve for communicating with “SMTP clients.”

The term “SMTP clients” relate to hosts who address Exchange on-Premises and ask from the Exchange server, to deliver \ forward the E-mail message to Exchange recipient or other external recipients.

The “Exchange interface \component ” which is dedicated to listening to the SMTP communication request (and sometime TLS protocol) is the Exchange receive connector.
The Exchange “SMTP listener” (the Exchange receive connector) is configured with default settings.

For example – by default, Exchange server receive connector is configured to accept anonymous (non-authenticated) SMTP connection from “entities” that want to deliver an email message to Exchange recipients.

The term Exchange recipients, define Exchange clients that have an Exchange mailbox or a recipient who has an E-mail address that uses the domain name which Exchange server is “responsible” for (authoritative domain).

In other words, by default any entity can address Exchange server, start an SMTP session and forward an E-mail message to Exchange recipients.

Although this “declaration” seems a little strange because the first association that appears in our mind could be that – this behavior is a “security issue” which can be used by hostile elements, we should not forget that by design, every mail server was created by default for communicating with “un-know” elements that represent “external entities”.

The entities that communicate Exchange server using SMTP
To explain the concept of anonymous SMTP connection, let’s use the following example: Exchange On-Premises represent the domain name – o365info.com

An external mail server addresses the Exchange on-Premises server and “ask him” to deliver an E-mail message to the recipient named John (John@o365info.com).

Because the Exchange on-Premises is responsible for the domain name – o365info.com, and because the Exchange hosts John’s mailbox, the Exchange server will “agree” to accept the E-mail message that is Intended to John@o365info.com.

Notice that in this scenario; the external mail server didn’t provide any credentials to the Exchange on-Premises server. This “behavior” is that standard mail flow that is implemented between the mail servers most of the time.

Addressing Exchange server using SMTP - No authentication is needed

Using an authenticated session

There are some scenarios, in which the communication between the mail servers (the Exchange server in the “other” mail server) will be configured in such a way that the external mail server will have to identify himself before the Exchange on-Premises server by providing a specific credential or a specific server certificate.
In the current article, we would not relate to such scenarios.

Exchange server and the receive connector

The Exchange component that “listens” to incoming SMTP requests for communication is the Exchange receive connector.

By default, Exchange uses a default receive connector, which is created automatically when we install Exchange server. The default Exchange receives connectors are created by using the following naming convention:

  • Client <Exchange server name>
  • Default <Exchange server name>

In the following screenshot, we can see an example for this Exchange receive connectors + an additional Exchange receives connectors that were created manually for specific mail flow needs.

Exchange authentication settings and the relationships with SMTP clients - 01

Exchange server and the receive connector authentication settings

As mentioned, by default, the Exchange receives connector is configured to support anonymous SMTP communication requests.

In the following screenshots, we can see the configuration settings on the Exchange receive connector named – Default EX01

The Exchange receive connector setting appears in three main tabs:

The Authentication tab | Exchange Receive connector

This tab is used for configuring the authentication protocol that Exchange server support.

As mentioned, Exchange receive connector doesn’t impose a mandatory requirement for authentication, so the obvious question that can appear is – why there is no option box named “no authentication” or where we can see the default setting in which Exchange server is configured to support anonymous access?

The answer is – not in the authentication tab, but instead, in another tab named – Permission Groups.

The authentication tab relates to a scenario in which we define a mandatory need for authentication.

For example, a scenario in which we need to define a mail flow with “another” mail server in which this mail server, will have to identify himself before the Exchange server.

In this scenario, the authentication tab will include in its list of authentication protocols, which can be used by the “other” mail server for identifying himself.

Exchange authentication settings and the relationships with SMTP clients - 02

The Permission Groups tab | Exchange Receive connector

The settings that include in the Permission Groups tab “dictate” if the Exchange server agrees to approve “anonymous communication” or only authenticated connection requests.

In the following screenshot, under the section – “Specify who is allowed to connect to this Receive connector” we can see a variety of options.

By default, the option of – Anonymous users is checked.

The term ” Anonymous users” is somewhat confusing because – the real meaning is not just “human users” but instead, any entity (mail enabled host or mail server) that try to communicate with Exchange server using SMTP.

The “other” options such as – Exchange users and Exchange servers are related to the relationships that Exchange server have with his Exchange clients (users whom their mailbox is hosted on the Exchange server) or the relationship with the “other Exchange servers” that belong to the same organization of the specific Exchange server.

Exchange authentication settings and the relationships with SMTP clients - 03

The Network tab | Exchange Receive connector

The network tab defines additional “filter” or parameters, that related to the “condition” in which Exchange server is willing to accept communication requests from “other entities”.

The additional parameters are:

  1. The IP address which represents the “other mail entity”
  2. The communication protocol port

In the following screenshot, we can see that the default setting on the Exchange receive connector.
Regarding the port number, Exchange receive connector is configured to “listen” to the standard mail communication protocol – the SMTP protocol that uses port 25.

Regarding the subject of “IP ranges”, we can see that by default, the Exchange server will “agree” to accept communication requests from any IP address. The concept of “any IP address” is represented by the subnet address – 0.0.0.0255.255.255.255

Exchange authentication settings and the relationships with SMTP clients - 04

Exchange and the subject of mail relay

The term that we want to review – “mail relay“, is quite confusing and unclear. In addition, in different scenarios the term “mail relay“, have different meanings.

Technically speaking, the term “mail relay” or ” SMTP relaying” defines a mail flow in which element A address element B asking him to deliver or forward the E-mail message to element C.

For example – recipient named John’s address Exchange mail server asking him to deliver an email message to a recipient named – Suzan.

In the following diagram, we can see an example to standard mail relay mail flow. In our specific example, the mail server (B) is responsible for the domain name o365info.com

When John (A) address the mail server and ask him to “deliver” E-mail message to a recipient who is hosted the mail server (Suzan@o365info.com), the mail server is “willing” to accept the E-mail message (relay the E-mail) because the mail server is authoritative for the domain name o365info.com and the destination recipient also belongs to this domain.

Most of the time, the “source recipient” (A) doesn’t need to prove his identity or provide user credentials because, the “main requirement” is fulfilled because the destination recipient Suzan@o365info.com) is under his authority of the Exchange server.

Mail relay

The additional use of the term – “mail relay”

The additional use for the term “mail relay” or the more common use, describes a scenario in which element A, address element B, asking him to deliver or forward E-mail message to element C.

The main difference from the previous scenario is that this time, the “destination recipient (element C) is not a recipient who is not part of the domain for which the mail server (element B) considers as authoritative.

In other words, the mail server that should accept the request for delivering the E-mail message to the destination recipient will need to find + address the mail server that represents the required domain and asks for him to deliver the E-mail message to the destination recipient.

For example, John (A) addresses the mail server and asks him to “deliver” E-mail message to a recipient named Alice@outlook.com

In this scenario, the Exchange server is not responsible for the specific domain,
the Exchange on-Premises server will need to find the MX record of the server that represents the domain outlook.com, connect him and ask him to deliver the E-mail message to Alice@outlook.com

Despite that the described scenario looks quite standard, this scenario is really a standard scenario only when the client that request to deliver the E-mail message to the external recipient is an authenticated client that Exchange server can “trust” and identify.

In case that the “client” that addresses the mail server (Exchange on-Premises in our scenario) is not an authenticated client (doesn’t provide user credentials), this could be a huge security risk because every hostile element can abuse the organization mail server and use the mail server is a “tool” for distributing spam mail, mail items with malware and so on.

We should prevent a scenario in which “everyone” could address, our mail server, and ask him to deliver an email message to the external recipient (recipient whom their domain name is not under the authority of our mail server).

Instead, we need to be sure that the element that asks to relay the E-mail message is a “legitimate factor” that can be trusted by the mail server.

Mail relay in Exchange based environment and the default settings

In Exchange based environment, to the option of “open relay” in disabled by default.

The term “open relay”, define a scenario in which mail server will accept requests to forward the E-mail message to “external recipient” from non-authenticated recipients (anonymous connection).
In Exchange based environment, the ability to use a mail relay to an external recipient via the Exchange server can be implemented only for authenticated recipients.

To be able to understand better the optional scenario that relates to mail relay to the internal + external recipient and the subject of authentication, let’s use the following scenario’s examples:

  • An organization that uses the public domain name – o365info.com
  • The organization Exchange server is authoritative for the domain name o365info.com

Scenario 1 – authenticated recipient | mail delivered to an internal recipient.

  • The source recipient is John@o365info.com
  • John’s mailbox is hosted on the Exchange on-Premises
  • John is the authenticated user
  • The destination recipient Suzan@o365info.com belongs to the same domain name as the source recipient

John addresses the local Exchange on-Premises, asking him to deliver an email message to Suzan@o365info.com

In this scenario, the Exchange on-Premises will “agree to forward” the E-mail message to Suzan because, Suzan “belong” to the o365info.com domain (the Exchange on-Premises is authoritative for the domain name o365info.com).

Exchange client - Asking from Exchange to deliver E-mail message to Exchange recipient-01

Scenario 2 – authenticated recipient | mail delivered to an external recipient

  • The source recipient is John@o365info.com
  • John’s mailbox is hosted on the Exchange on-Premises
  • John is the authenticated user
  • The destination recipient is Alice@outlook.com
  • The destination recipient considered as “external recipient”

John addresses the local Exchange on-Premises, asking him to deliver an email message to Alice@outlook.com

Notice that Alice E-mail address, include an “external domain name” meaning – a domain name that from the Exchange on-Premises point of views consider as -“external domain” or non-authoritative domain.

The be able to deliver the E-mail message to the destination recipient, Exchange on-Premises will need to address the “external mail server” that is responsible (represent) the domain name outlook.com

In this scenario, the Exchange on-Premises will “agree to forward” the E-mail message to Alice@outlook.com because John is the authenticated user.

Exchange client -Asking from Exchange to deliver E-mail message to non- Exchange recipient -02

Scenario 3 – non-authenticated recipient | mail-enabled device | mail delivery to internal recipient

  • The source recipient is mail- enabled device such as a printer
  • The mail-enabled device is not authenticated user (doesn’t provide user credentials)
  • The destination recipient is Suzan@o365info.com
  • The destination recipient considered as “internal recipient”

The mail-enabled device addresses the local Exchange on-Premises, asking him to deliver
an email message to Suzan@o365info.com

In this scenario, the Exchange on-Premises will “agree to forward” the E-mail message to Suzan because, Suzan “belongs” to the o365info.com domain (the Exchange on-Premises is authoritative for the domain name o365info.com) although the user is not identified (the mail-enabled device).

Mail enabled device -Asking from Exchange to deliver E-mail message to Exchange recipient -03

Scenario 4 – non-authenticated recipient | mail-enabled device | mail delivery to external recipient

  • The source recipient is the mail-enabled device such as a printer
  • The mail-enabled device is not authenticated user (doesn’t provide user credentials)
  • The destination recipient is Alice@outlook.com
  • The destination recipient considered as “external recipient”

The mail-enabled device addresses the local Exchange on-Premises, asking him to deliver
an email message to Alice@outlook.com

Notice that Alice E-mail address, include an “external domain name” meaning – a domain name that from the Exchange on-Premises point of views consider as -“external domain” or non-authoritative domain.

The be able to deliver the E-mail message to the destination recipient, Exchange on-Premises will need to address the “external mail server” that is responsible (represent) the domain name outlook.com

In this scenario, by default, the Exchange on-Premises will not agree to forward the E-mail message to Alice@outlook.com because the mail-enabled device is not an authenticated user (didn’t provide user credentials).

Mail enabled device -Asking Exchange to deliver E-mail message - NON Exchange recipient -04

Trying to relay via an Exchange server using anonymous SMTP session an example

In the following section, I would like to demonstrate the process of SMTP-based communication with the Exchange-based server using an anonymous session (non-authenticated session) and a telnet client.
Using the telnet client, enables us to get a “behind the scenes” view of the session channel that is created between the host, who tries to communicate the Exchange server and the Exchange server response.
In our particular scenario, the Exchange considers as authoritative for the domain name – o365info.com
We will demonstrate two different scenarios of communication requests:

Case 1 – the non-authenticated host, address Exchange and ask to deliver a \forward E-mail message to a recipient who considers as an internal recipient (the Exchange server represents the particular domain name).

Case 2 – the non-authenticated host, address Exchange and ask to deliver a \forward E-mail message to a recipient who considers as the external recipient the meaning is that the Exchange server is not authoritative for the domain name, and he will need to contact the outer mail server that is responsible for the destination domain.

Case 1 – non-authenticated host asks to deliver an email message to the internal Exchange recipient
In the following screenshot, we can see an example of a telnet session.

The element that addresses the Exchange server asks to deliver an email message to a recipient named – Suzan@o365info.com

Because, in our scenario, the Exchange server is responsible for this domain, Exchange will agree to deliver the message to the destination recipient.

In the screenshot, we can see that the Exchange server to inform the host that they accept the E-mail, and the E-mail Queued mail for delivery.

Trying to relay via Exchange server using anonymous SMTP session -01

Case 2 – non-authenticated host asks to deliver an email message to the external recipient
In the following screenshot, we can see the “un-authenticated” host address Exchange server, and ask him to deliver an email message to an “external E-mail recipient” – Alice@outlook.com

Because the host not authenticated, the Exchange Online refuses to forward the E-mail (the Exchange doesn’t support the option of “open relay”).

The Exchange server response are – unable to relay

Trying to relay via Exchange server using anonymous SMTP session -02

Exchange on-Premises | Allow Anonymous Relay on a Receive Connector

As mentioned, by default Exchange server will not accept anonymous SMTP session from a host who needs to relay an email message to the external recipients.

In other words, by default Exchange on-Premises is configured not to support the option on “open relay” which enabled un-authenticated hosts, to address Exchange and ask him to deliver an email message to external recipients.

In some scenario, we will need to “bypass” this restriction by enabling specific un-authenticated hosts (anonymous SMTP session) to address Exchange server and ask Exchange server to deliver email messages to the external recipient.

To be able to provide this “mail relay service” only to specific hosts or a specific “allowed” mail enabled devices, we will identify this host by their IP address.

Note – technically speaking they need to identify the hosts by IP address is not a mandatory requirement, but it’s not recommended and not ” Wise” to implement such as configuration.

Configuring Exchange receive connector to relay requests from specific hosts

In this scenario, we could fulfill this requirement by using two steps:

  1. Create a dedicated Exchange receive connector
  2. Configure the Exchange receive connector to accept anonymous requests from a particular IP address

The scenario is as follows:

  • The IP address of the Exchange mail server is 10.0.0.50
  • The IP address of the mail-enabled host is – 10.0.0.80

In the following example, we will implement the two steps by using PowerShell.

Step 1 – Create a new receive connector.

We will create a deducted Exchange on-Premises receive connector that will “listen” to the specific host requests.

New-ReceiveConnector -Name "Anonymous Relay" -Usage Custom -PermissionGroups AnonymousUsers -Bindings 10.0.0.50:25 -RemoteIpRanges 10.0.0.80

Step 2 – Grant relay permission to anonymous connections on the new Receive connector

In step 2, we need to change the default Exchange receive connector setting so Exchange will “agree” to implement the mail relay process for hosts that doesn’t provide user credentials and can be identified by their IP address.

Get-ReceiveConnector "Anonymous Relay" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "Ms-Exch-SMTP-Accept-Any-Recipient"
o365info Team

o365info Team

This article was written by our team of experienced IT architects, consultants, and engineers.

This Post Has 0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *