Exchange architecture and default opportunistic TLS settings |Part 3#12 5/5 (1) 15 min read

In the following article, we will review in more details that implementation of opportunistic TLS on Exchange on-Premises based environment and also in the Exchange Online-based environment.

As mentioned, in the Exchange-based environment, the Exchange mail connectors are automatically configured to use the option of opportunistic TLS.

The configuration of opportunistic TLS is automatically configured on the default incoming mail connector and, on the default outgoing mail connector.

Exchange on-Premises infrastructure | opportunistic TLS settings

In the following section, we will review the default settings of opportunistic TLS in Exchange on-Premises server environment.

The opportunistic TLS settings are automatically configured on the Send connector and Receive connector.

Exchange on-Premises - Send and receive connector - opportunistic TLS settings

Note – In the current section, we will demonstrate the opportunistic TLS settings in Exchange 2010 on-Premises but the concept and the settings, are almost identical to Exchange 2013 on-Premises.

Exchange on-Premises | Send connector | opportunistic TLS settings

In Exchange 2010 and Exchange 2013, the information about the default settings of the opportunistic TLS that are used by the Send connector can be displayed only by using PowerShell.

To be able to get information about the Send connector settings, we can use the following PowerShell command:

Get-SendConnector -Identity “<name of the send connector>” |FL

The parameter that relates the setting of the opportunistic TLS described as IgnoreSTARTTLS

In the following screenshot, we can that the value of IgnoreSTARTTLS is False

The meaning is that by default, the Exchange on-Premises Send connector supports the option of opportunistic TLS.

Exchange on-Premises server - Receive connector - opportunistic TLS -00

Disabling the option of opportunistic TLS

I cannot think of as a scenario in which we will need to disable the option of opportunistic TLS, but just for a general knowledge, in case that, for some reason, we need to cancel the option of opportunistic TLS, we can use the PowerShell command:

Set-SendConnector -Identity “<name>” -IgnoreSTARTTLS $true

Exchange on-Premises | Receive connector | opportunistic TLS settings

In Exchange 2010 and Exchange 2013 server version, some of the information about the default setting of the Receive connector that refers to the option of opportunistic TLS, can be displayed in the graphic interface and, some information can be displayed only by using PowerShell.

Viewing the Exchange on-Premises Receive connector settings using PowerShell

To be able to get information about the Receive connector settings, we can use the following PowerShell command:

Get-ReceiveConnector -Identity “<name of the receive connector>” |FL

The information about the “TLS settings” of the Receive connector, appears under the section named – AuthMechanism

The AuthMechanism parameter can contain multiple values, meaning that Exchange Receive connector can support many types of authentication protocols.

In the following screenshot, we can see an example of the settings of the standard Exchange on-Premises server default Receive connector

We can see that the value of AuthMechanism includes many types of authentication protocols:

Exchange on-Premises server - Receive connector - opportunistic TLS

AuthMechanism settings

We can see that Exchange Receive connector support different type of authentication protocol.

Regarding the subject of TLS, we can see two relevant parameters

1. Tls

This is the parameter that “activate” the option of opportunistic TLS

The meaning is that, in a scenario in which other mail server try to communicate with the Exchange server, the Exchange server will offer to use TLS.
If the “other mail server” doesn’t support TLS, the Exchange server will “agree” to use the SMTP protocol instead.

Note – my opinion is that the definitions of the opportunistic TLS under the section of AuthMechanism are a little Inaccurate because, technically, the TLS protocol doesn’t dictate a mandatory need for authentication.

2. BasicAuthRequireTLS

This option is relevant, mainly for a scenario in which mail client (such as POP3 or IMAP4 mail client) address Exchange on-Premises, asking for “retrieving” mail items.

In this case, the mail client will need to identify by providing user credentials.

Most of the mail client will “deliver” the user credentials by using basic authentication (BasicAuth) in which the user credentials will not encrypted.

The option of – BasicAuthRequireTLS instruct the mail client to deliver the user credentials over a secure communication channel (TLS) and, not by using a standard communication channel (non-encrypted communication channel).

3. Require TLS

The second parameter in Exchange on-Premises Receive connector include additional parameter that relates to configuration of Force TLS named – Require TLS

We will briefly discuss this option in the article – xxx

Viewing the Exchange on-Premises Receive connector settings using the Exchange Graphic interface

When we use the Exchange Graphic interface, for viewing the settings that related to the option of opportunistic TLS, it’s important to emphasize that only one parameter is directly related to opportunistic TLS.

In the following screenshot, we can see that we can select one of the following options:

1. Transport Layer Security (TLS)

Selecting this option will “activate” the option of opportunistic TLS in the Exchange on-Premises Receive connector .

This is the only option that is relevant to the subject of “server to server” communication and the feature of opportunistic TLS.

2. Enable Domain Security (MutualAuth TLS).

This option relates to a very specific configuration named – domain security.
As far as I understand, the option of domain security is relevant only for a scenario in which the two involved parties are Exchange on-Premises based servers.

3. Basic Authentication

The option of – Offer Basic Authentication only after starting TLS is relevant to “client to server” scenario, in which mail client that uses POP3/IMAP4 need to connect the Exchange on-Premises server by using TLS protocol. The user credentials that need to be “send” to the mail server (Exchange on-Premises in our scenario) will transfer over the TLS secure communication line.

Exchange on-Premises server - Receive connector - opportunistic TLS -03

Attached a quotation from a Microsoft article that describes the different TLS option that can set by selecting a particular option:

  • Transport Layer Security (TLS) – Select this option to offer Transport Layer Security (TLS) transmission for all messages received by this connector. When you select this option, the STARTTLS keyword is advertised in the EHLO response to connecting SMTP servers, and TLS authentication is accepted.
  • Enable Domain Security (Mutual Auth TLS) – To instruct this Receive connector to accept a mutual TLS connection from a remote server, select this check box. There are additional configuration steps required before you can enable mutual TLS. For more information about configuring mutual TLS, see Using Domain Security: Configuring Mutual TLS.
  • Offer Basic Authentication only after starting TLS – When you select this option, the connector starts TLS first, and then after TLS encryption is complete, the connector offers Basic authentication.
[Source of information – Configure Receive Connector Properties]

How can I know that my Exchange on-Premises support opportunistic TLS?

In case that we want to verify if a specific mail server supports the option of communication using the TLS protocol, we can Telnet the specific server and, use the EHLO command, to get a list of the supportable options that existed on the “destination server”.

For example, we will telnet the mail server that represents the domain name – o365info.com by using the following Telnet syntax:

How to Use Telnet to Test SMTP Communication -01

In the following screenshot, we can see the results:

How to Use Telnet to Test SMTP Communication -02

One of the commands that appear in the list is – 250-STARTTLS

If “250-STARTTLS” is listed in the response, opportunistic TLS is offered.

Exchange Online | outbound and inbound mail connectors

In the current section and in the next section, we will review the subject of opportunistic TLS in Exchange Online based environment.

As mentioned, in an Exchange Online based environment, we use different terms for describing the mail connectors.

  • Outgoing mail connectors referred as – outbound connector
  • Incoming mail connectors referred as – inbound connector

Ok, now to an interesting fact – by default, Exchange Online doesn’t include any default mail connectors that appear in the Exchange Online admin management interface!

Exchange Online environment considers as a SaaS (Software as a service).

In Office 365 and Exchange Online environment, there is no “dedicated” mail server for a particular Office 365 tenant, but instead, an array of mail servers who serve and represent all the Office 365 tenants.

Exchange Online inbound connector

Exchange Online, uses a “dedicated” inbound connector for each of the Office 365 domain tenant who are registered at Office 365 and configured for mail use, but the setting of this inbound connector doesn’t appear in the Exchange Online admin management interface.

Exchange Online Outbound connector

All we know is that regarding the Outgoing mail infrastructure, Exchange Online uses the EOP (Exchange Online Protection) as an infrastructure for Outgoing mail + incoming mail.

The “outgoing” mail for all the Office 365 tenants, is delivered via the EOP (Exchange Online Protection) array of servers.

An obvious question that can appear is:

Q: Can I create a custom outbound connector + Inbound connectorr in the Exchange Online environment for my tenant?

A: The answer is “Yes”, we can create a custom outbound connector + inbound connector that will serve for – implementing a specific routing scenario, specific authentication scenario or, for configuring a secure communication channel using TLS.

Later on in the article xx, we will review the subject of creating and configuring custom outbound connector + inbound connector in the Exchange Online based environment.

Exchange Online environment uses EOP for incoming and Outlook going mail flow

Exchange Online infrastructure | inbound mail connector |The two entities of opportunistic TLS and force TLS

In the former section, we declared that by default, Exchange Online doesn’t include any connectors that appear in the Exchange Online admin management interface but Exchange Online includes:

  1. An inbound connector that is “attached” to a specific Office 365 tenant domain name.
  2. Generic inbound connector” that is not attached to a specific domain name. This general inbound connector is “attached” to the public hostname – office365.com

Technically speaking, an external mail server that needs to address Exchange Online server who represents a specific domain name (Office 365 tenants who register his public domain name at Office 365), can address Exchange Online infrastructure by using two methods:

  1. Addressing the hostname who appears in the MX record
  2. Addressing a “general hostname” – the smtp.office365.com

The main difference between the two Exchange Online “entities” is the TLS settings.

  • The Exchange Online entity that appears in the MX record is configured to use opportunistic TLS.
  • The Exchange Online entity that is represented by the host name – office365.com is configured to use the option of Force TLS

In other words, when a mail server addresses the host name – smtp.office365.com, the Exchange Online “demand” that the communication will be implemented as a secure communication channel using the TLS protocol.

Addressing Exchange Online by using the hostname who appears in the MX record

A “standard mail communication”, in which external mail server tries to address the Exchange Online server who represents a specific domain, will be implemented by looking for the MX record that represents a specific domain.

In Office 365 and Exchange Online environment, we publish the MX record using a hostname which is represented by Exchange Online infrastructure.

For example, the domain name o365pilot.com was registered with Office 365, and the mail infrastructure is hosted at Exchange Online.

The hostname who appears in the MX record that “point out” the mail server that represents this domain is based on the following naming convention.

The Exchange Online host name that represent a public registered domain name

In our specific scenario, the host name will be – o365pilot-com.mail.protection.outlook.com

The Exchange Online hostname who appears in the MX record is “bound” to Exchange Receive connector that supports the option of opportunistic TLS.

In a scenario, in which external mail server addresses the Exchange Online hostname who accounts for a specific Office 365 tenant using SMTP protocol, Exchange Online will try to offer the use of TLS protocol instead.

  • In the case that the external mail server (the source server) also supports the option of TLS, the communication channel will be implemented by using TLS.
  • In the case that the external mail server (the source server) doesn’t support, the option of TLS, the communication channel will be implemented by using SMTP.

In the following diagram, we can see an example of a mail flow scenario in which external mail server address Exchange Online server, by using the Hostname, who appears in the MX record.

The external mail server can “choose” between using non-encrypted mail Protocol – SMTP or encrypted mail protocol – TLS.

Addressing Exchange Online by using the host name that appear in MX record

Q: How do I know that the Exchange Online host name that represents my domain support opportunistic TLS?

A: We will try to create an SMTP telnet session with the Exchange Online hostname who represents Office 365 tenant.

In our example, my public domain name who was registered at Office 365 is – o365info.com

The host name that appears in the MX record for the domain name – o365info.com is:
o365info-com.mail.protection.outlook.com

When will try to telnet this hostname, by using the command

Telnet o365info-com.mail.protection.outlook.com 25

Addressing Exchange Online by using the host name that appear in MX record -01

In the following screenshot, we can see that after we type the EHLO command, the Exchange Online server reply with a list of “supported option”. One of this option is the command – 250-STARTTLS

In this stage, we cannot be sure of the host support Force TLS or opportunistic TLS

Addressing Exchange Online by using the host name that appear in MX record -02

To be able to verify if the server (Exchange Online) also supports “standard SMTP” session, we will try to create a standard SMTP session by using the following command:

Mail from: <Recipient name>

In the following screenshot, we can see that the Exchange Online server reply with the “answer”: 250 2.1.0 Sender OK

The meaning is that we can use a “standard SMTP” session

Addressing Exchange Online by using the host name that appear in MX record -03

Addressing Exchange Online by using the hostname smtp.office365.com

The additional Exchange Online entity is represented by the hostname smtp.office365.com

Technically speaking, the “smtp.office365.com Exchange Online entity” can represent all the Office 365 tenets that hosted at Exchange Online infrastructure.

In other words, in case that a mail server needs to address the Exchange Online mail server that represents specific Office 365 tenant (specific public domain name), the external mail server can address the host smtp.office365.com, instead of looking for the MX record that represents the particular Office 365 domains.

The main purpose of the “Exchange Online smtp.office365.com entity” is to enable only secure mail communication meaning Force TLS.

In other words, the only way to address the Exchange Online smtp.office365.com entity is by using TLS.

An example of a scenario in which we need to address the Exchange Online smtp.office365.com entity is, a scenario; in which we have mail-enabled application or, a mail-enabled device that needs to “use” the Exchange Online server for sending mail.

In the past, the only possible way of implementing this type of scenario was by configuring the mail-enabled device\application to address the hostname –
smtp.office365.com

The biggest obstacle of this requirement was that most of the mail-enabled devices don’t support TLS.

In nowadays, the solution is simpler, because we can configure the mail-enabled the device to use the “standard” Exchange Online host name without the need of a mandatory requirement to use TLS.

Note – to be enabled mail-enabled device\application to address Exchange Online server using SMTP and send mail to an internal + external recipient, we will need to create manually an inbound connector that will identify this mail client by their public IP address.

In the following diagram, we can see an example of a mail flow that usually implemented when a mail-enabled device or application addresses the Exchange Online server by using the pre-defined Hostname smtp.office365.com

Addressing Exchange Online by using the host name smtp.office365.com

Q: How do I know that the Exchange Online hostname smtp.office365.com support only Force TLS?

A: We will try to create an SMTP telnet session with the Exchange Online hostname smtp.office365.com

When will try to telnet this hostname, by using the command

Telnet smtp.office365.com 25

Addressing Exchange Online by using the host name smtp.office365.com -01

In the following screenshot, we can see that after we type the EHLO command, the Exchange Online server reply with a list of “supported option”. One of this option is the command – 250-STARTTLS

In this stage, we cannot be sure of the host support Force TLS or opportunistic TLS

To be able to verify if the server (Exchange Online) supports also “standard SMTP” session, we will use the command:

Mail from: <Recipient name>

In the following screenshot, we can see that the Exchange Online server replies with the “answer”:

530 5.7.57 SMTP; Client was not authenticated to send anonymous mail during MAIL FROM

The meaning is that we cannot use a “standard SMTP” session

Addressing Exchange Online by using the host name smtp.office365.com -02

Note – the standard cmd telnet client doesn’t support the option of using the TLS protocol

Next article

The next article (Configuring the option of Force TLS in Exchange on-Premises environment | Part 4#12) in the TLS article series, is dedicated to the subject of – Configuring the option of Force TLS on Exchange on-Premises environment

Opportunistic TLS and Force TLS in Exchange environment | Article series index

Now it’s Your Turn!
It is important for us to know your opinion on this article

Summary
Exchange architecture and default opportunistic TLS settings |Part 3#12
Article Name
Exchange architecture and default opportunistic TLS settings |Part 3#12
Description
In the following article, we will review in more details that implementation of opportunistic TLS on Exchange on-Premises based environment and also in the Exchange Online-based environment.
Author
Publisher Name
o365info.com
Publisher Logo

Related Post

Please rate this

Eyal Doron on EmailEyal Doron on FacebookEyal Doron on GoogleEyal Doron on LinkedinEyal Doron on PinterestEyal Doron on RssEyal Doron on TwitterEyal Doron on WordpressEyal Doron on Youtube
Eyal Doron
Share your knowledge.
It’s a way to achieve immortality.
Dalai Lama

Leave a Reply

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