[ad_1]
The SMTP protocol isn’t secure and wasn’t designed to be. Email sent in the early days of the Internet were the digital equivalent of sending a postcard through the postal system. Eventually, Transport Layer Security (TLS) encryption was added to protect SMTP communications. But to maintain backward compatibility, it was never made compulsory and even today it’s used only opportunistically by senders.
TLS uses certificates for encryption, but they aren’t used for verifying the identity of the destination server. This exposes SMTP connections to DNS tampering that can redirect connections to an attacker’s server. Senders have no way to confirm that destination server is the intended email server. Even worse, after intercepting traffic, a savvy attacker can relay it to the intended destination, and neither the sender nor the recipient would be aware that a man-in-the-middle attack ever took place.
The SMTP MTA Strict Transport Security (MTA-STS) standard was developed to ensure that TLS is always used, and to provide a way to for sending servers to refuse to deliver messages to servers that don’t support TLS and have a trusted certificate. The MTA-STS standard was developed by several email industry companies brought together by the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG). We have been validating our implementation and are now pleased to announce support for MTA-STS for all outgoing messages from Exchange Online.
Outbound Protection
All outbound Exchange Online email traffic is covered by this new security feature, and there’s nothing admins need to do to leverage it. Our outbound implementation respects the wishes of the recipient domain owners via their MTA-STS policy. MTA-STS now forms part of the security infrastructure of Exchange Online, and it’s always on (like other core SMTP features).
Inbound Protection
Nothing new is needed from Exchange Online to leverage MTA-STS protection for your own domains. Exchange Online supports TLS1.2 and offers the TLS certificates that are required by the standard. As domain owners ourselves, we secured several of our own domains, including primary domains such as outlook.com, hotmail.com, and live.com. Therefore, we’re now assured that connections from senders who support MTA-STS are much better protected against man-in-the-middle attacks. If a sender does not perform MTA-STS validations, email will still be delivered as normal, and TLS will be used if the sender chooses to use it.
NOTE: Messages will be delivered when only one party supports MTA-STS. For example, when an MTA-STS-protected domain receives a message from a sender domain that doesn’t support MTA-STS, the message is delivered. The message is also delivered when the recipient domain doesn’t support MTA-STS, but the sender domain does. The only scenario where messages aren’t delivered is when both sides are using MTA-STS and MTA-STS validation fails.
MTA-STS allows a domain to declare support for TLS and communicate the MX record and destination certificate to expect. It also indicates what a sending server should do if there’s a problem. This is done through a combination of a DNS TXT record and a policy file that’s published as an HTTPS web page. The HTTPS-protected policy introduces another security protection that attackers must overcome.
A domain’s MTA-STS TXT record indicates MTA-STS support to a sender, after which the domain’s HTTPS-based MTA-STS policy is retrieved by the sender. The following TXT record is an example that declares support for MTA-STS:
_mta-sts.contoso.com. 3600 IN TXT v=STSv1; id=20211201000000Z;
A domain’s MTA-STS policy is located at a predefined URL that’s hosted by the domain’s web infrastructure. The URL syntax is https://mta-sts.<domain name>/.well-known/mta-sts.txt. For example, Microsoft.com’s policy is found at: https://mta-sts.microsoft.com/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: *.mail.protection.outlook.com
max_age: 604800
Any customers whose MX records point directly to Exchange Online can use this same policy. The unique, required information in the policy is the MX record that points to Exchange Online, and the same certificate is shared by Exchange Online customers.
To be protected by MTA-STS, a domain owner needs to create the DNS TXT domain record and host the policy file at the required HTTPS URL with a valid certificate that contains their domain. Details about MTA-STS are available in RFC 8461.
Staying Informed Through TLS-RPT Reports
Accompanying MTA-STS is an extremely useful industry specification that outlines a standard mechanism to allow email services to report sending issues that occur when sending to a specific domain. This is the first time a channel is available for domain owners to get direct reports of actual issues that senders encounter when sending email to the domain. This reporting mechanism can avoid the need for senders to report issues related to sending email to your domain.
The TLS-RPT standard provides reporting for MTA-STS (and DANE for SMTP) with a single daily report from each email service that supports it. To receive TLS-RPT reports, a domain owner can create a DNS TXT entry to indicate where they would like to receive reports. For most admins, it means sending the reports to an email address, as shown in the following example:
TXT Record example: _smtp._tls.example.com. 3600 IN TXT TLSRPTv1;rua=mailto:reports@example.com
Email services that send email to your domain and that support both MTA-STS and TLS-RPT send daily reports to the provided email address. Details about TLS-RPT are available in this RFC 8460. Microsoft has started sending TLS-RPT reports to domains that have requested them.
MTA-STS Failures
If an MTA-STS check fails and the domain’s policy is set to enforce, an NDR will be generated and the message will not be sent. The following list describes the errors that might occur due to MTA-STS failures:
- Destination server does not support TLS
551 5.7.4 STARTTLS is required by recipient domain’s MTA-STS policy
- Destination server does not support TLS 1.2 or above
551 5.7.6 MTA-STS requires TLS 1.2 or higher. TLS Version: <Observed TLS version>
- Domain’s MX record failed MTA-STS validation
551 5.4.8 MX hosts of ‘<Domain>’ failed MTA-STS validation.
- The destination’s certificate must contain the hostname in the MX record
551 5.7.5 Remote certificate MUST have a subject alternative name matching the hostname (MTA-STS)
- The destination’s certificate failed validation
551 5.7.5 Remote certificate failed MTA-STS validation. Reason: <Reason>
Implementation
We try to respect RFCs to the best of our abilities. The goal is to achieve the best interoperability possible. In a small number of scenarios, there may be unexpected behavior, and we’ll do our best to document that behavior.
For example, one difference in behavior involves CNAME records and MX records. Having a CNAME record for an MX record doesn’t comply with the SMTP RFC, but in the interest of successfully sending the email of our customers, we currently resolve CNAMEs to the servers that they point to for message deliveries. For MTA-STS, we’ve taken a stricter approach to supporting the RFC. We do not support CNAMEs when MTA-STS is used. If a domain uses a CNAME and follows the MTA-STS RFC, that domain will fail our MTA-STS checks, and will not receive emails from us. However, it’s possible for a domain to include the final server in their MTA-STS policy and pass our MTA-STS checks, even though that would not strictly follow the MTA-STS RFC.
MTA-STS Vs SMTP DANE
MTA-STS came about because of the slow roll out of DNSSEC to protect the DNS records that are associated with SMTP. MTA-STS can be seen as a lighter-weight mechanism to secure your mail flow. Although MTA-STS offers a much-needed upgrade to current SMTP protections, DANE for SMTP (with the support of DNSSEC) is the gold standard for securing SMTP connections. However, many customers might find MTA-STS good enough for their security needs.
We’ve been working on support for both MTA-STS and DANE for SMTP. At the very least, we encourage customers to secure their domains with MTA-STS. You can use both standards on the same domain at the same time, so customers are free to use both when Exchange Online offers inbound protection using DANE for SMTP by the end of 2022. By supporting both standards, you can account for senders who may support only one method.
Both MTA-STS and DANE require adoption from domain owners on the receiving side and services/servers that send email. We strongly encourage everyone to adopt these standards to improve the overall security of SMTP connections. Currently, we successfully validate connections to over 35K MTA-STS-protected domains, and this number is growing every month.
Future Work
We’re actively working on features that are related to the MTA-STS and DANE for SMTP standards with the goal of making it easier for our customers to make the most of them. We’ll announce these features as they become available.
Source link
