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 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:
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.
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:
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:
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:
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.
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.
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:
In the following screenshot, we can see the results:
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 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:
- An inbound connector that is “attached” to a specific Office 365 tenant domain name.
- “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:
- Addressing the hostname who appears in the MX record
- 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.
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.
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
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) 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 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.
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
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
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
Note – the standard cmd telnet client doesn’t support the option of using the TLS protocol