MTA-STS email security

Discuss your pilot or production implementation with other Zimbra admins or our engineers.
User avatar
JDunphy
Outstanding Member
Outstanding Member
Posts: 889
Joined: Fri Sep 12, 2014 11:18 pm
Location: Victoria, BC
ZCS/ZD Version: 9.0.0_P39 NETWORK Edition

MTA-STS email security

Post by JDunphy »

Google appears to be going with MTA-STS email security so this has repercussions to those using self-signed certificates if they want to send email to google.
A MTA-STS policy for your domain means that you request external mail servers sending messages to your domain to verify the SMTP connection is authenticated with a valid public certificate and encrypted with TLS 1.2 or higher. This can be combined with TLS reporting, that means your domain can request daily reports from external mail servers with information about the success or failure of emails sent to your domain according to MTA-STS policy.
Ref: https://security.googleblog.com/2019/04 ... h-mta.html
User avatar
pup_seba
Outstanding Member
Outstanding Member
Posts: 687
Joined: Sat Sep 13, 2014 2:43 am
Location: Tarragona - Spain
Contact:

Re: MTA-STS email security

Post by pup_seba »

We need a "thumbs up" in this forum :) Thanks for the heads up!
milauria
Advanced member
Advanced member
Posts: 96
Joined: Mon Aug 15, 2016 12:32 pm

Re: MTA-STS email security

Post by milauria »

I have been watching all the Zimbra seminars on email security and MTA-STS and found them a great help, thanks a million for taking the time to make them.

One configuration though that I have not been able to sort for the MTA-STS, I have religiously followed the setup steps(I think) by creating the https://mta-sts web record that I can query plus a letsencrypt certificate plus the DNS settings.

to be noted that the https certificate has been created for teh main website http://www.xxx.com and I have added as alternative DNS names the virtual hosts : mail.xxx.com , mta-sts.xxx.com*

the google & microsoft report gives me the below error:

[{"result-type":"certificate-not-trusted","receiving-mx-hostname":"mail.xxxx.com","receiving-ip":"xx.xx.xx.xx","failed-session-count":11}]}]}

Any idea if (for example) it is because I need to create a dedicated certificate for host mta-sts.xxx.com (ie not ok to add this as alternative certificate name) ?
I have used a validator I found online and it says "all OK"
https://www.mailhardener.com/tools/mta- ... n=xxxx.com

Thanks for any hint that you can provide
User avatar
andras0602
Advanced member
Advanced member
Posts: 62
Joined: Sat May 21, 2022 3:11 pm
ZCS/ZD Version: 8.8.15

Re: MTA-STS email security

Post by andras0602 »

milauria wrote:I have been watching all the Zimbra seminars on email security and MTA-STS and found them a great help, thanks a million for taking the time to make them.

One configuration though that I have not been able to sort for the MTA-STS, I have religiously followed the setup steps(I think) by creating the https://mta-sts web record that I can query plus a letsencrypt certificate plus the DNS settings.

to be noted that the https certificate has been created for teh main website http://www.xxx.com and I have added as alternative DNS names the virtual hosts : mail.xxx.com , mta-sts.xxx.com*

the google & microsoft report gives me the below error:

[{"result-type":"certificate-not-trusted","receiving-mx-hostname":"mail.xxxx.com","receiving-ip":"xx.xx.xx.xx","failed-session-count":11}]}]}

Any idea if (for example) it is because I need to create a dedicated certificate for host mta-sts.xxx.com (ie not ok to add this as alternative certificate name) ?
I have used a validator I found online and it says "all OK"
https://www.mailhardener.com/tools/mta- ... n=xxxx.com

Thanks for any hint that you can provide
It's a bit messy. I guess xxx.com or xxxx.com is not your real domain. Why did you put a wildcard after mta-sts.xxx.com* ?
Could you share the content of your certificate with us? I don't mind if you redact or replace the domain but do it consistently.
milauria
Advanced member
Advanced member
Posts: 96
Joined: Mon Aug 15, 2016 12:32 pm

Re: MTA-STS email security

Post by milauria »

You are right, sorry for not being precise.

The SSL checker online says this (do you need to see more details from the certificate?)

Code: Select all

Common Name = www.mydomain.it
Subject Alternative Names = autodiscover.mydomain.it, mail.mydomain.it, mta-sts.mydomain.it, www.mydomain.it
the policy file can be queried pointing the browser at: https://mta-sts.mydomain.it/.well-known/mta-sts.txt

Code: Select all

version: STSv1
mode: testing
mx: mail.mydomain.it
max_age: 31557600
The DNS records for mydomain.it includes:

Code: Select all

_mta-sts	10800 IN TXT	"v=STSv1; id=2022051601"
_smtp._tls	10800 IN TXT	"v=TLSRPTv1; rua=mailto:postmaster@mydomain.it"
@	10800	IN	MX	10 mail.mydomain.it.
Have I misconfigured something ? I am on ZCS OSE 8.8.15 with always latest patches installed on Centos 7
Many thanks
User avatar
rleiker
Advanced member
Advanced member
Posts: 149
Joined: Tue Jan 07, 2020 8:23 pm
Location: Kansas City
Contact:

Re: MTA-STS email security

Post by rleiker »

Hi milauria,

Glad to hear you like the Zimbra security webinar series (https://www.youtube.com/watch?v=YcpGtvKJQ2c). You mentioned that Microsoft and Google are sending you feedback about failed STARTTLS connection failures to your Zimbra server, I presume within their TLS-RPTs that contain:

Code: Select all

[
	{
		"result-type": "certificate-not-trusted",
		"receiving-mx-hostname": "mail.xxxx.com",
		"receiving-ip": "xx.xx.xx.xx",
		"failed-session-count": 11
	}
]
This RFC (https://datatracker.ietf.org/doc/html/r ... tion-4.3.1) describes the errors that you may see in a TLS-RPT in more detail, but the one that stands out in the TLS-RPTs that you are receiving is the "certificate-not-trusted" error that should be the focus of your troubleshooting. This is a catch-all error that indicates that something is wrong with the SSL certificate either on your MX server or on your web server where the mta-sts.txt file is being hosted. Examples might include a broken SSL certificate chain, like using the wrong intermediate or root certificate, or where the server's host name does not exactly match either the certificate's name or one of its SANs (subject alternate names). My webinar co-host Barry de Graaf was kind enough to recently write a how-to blog post on this topic too: https://blog.zimbra.com/2022/05/zimbra- ... ate-chain/.

For example, if your DNS MX record for mydomain.it points to mail.mydomain.it, then your SSL certificate on your MX server must exactly match the "mail.mydomain.it" sub-domain. Or, if the DNS MX record for mydomain.it points to spamtrap.somedomain.com, then your SSL certificate for your MX server must exactly match "spamtrap.somedomain.com". It is perfectly fine for these to appear as either the SSL certificate's "Issued To" name, or as one of the SANs in the certificate.

Additionally, recall from the webinar that 2 other requirements are:
  • Your MX server and the web server hosting the mta-sts.txt file must support TLSv1.2, TLSv1.3, or newer.
  • Your MX server must support opportunistic encryption, in other words the STARTTLS command.
The sample mta-sts.txt file that you included from your web server looks good, so no problems there, but you have an error in your one of your DNS TXT records:

Code: Select all

_mta-sts   10800 IN TXT   "v=STSv1; id=2022051601"
needs to be (missing semicolon):

Code: Select all

_mta-sts   10800 IN TXT   "v=STSv1; id=2022051601;"
milauria
Advanced member
Advanced member
Posts: 96
Joined: Mon Aug 15, 2016 12:32 pm

Re: MTA-STS email security

Post by milauria »

Many thanks for the explanation and this made me think about few issues … computers never lie !

Actually my Zimbra server runs behind a reverse proxy and has its own self-signed certificate. While the reverse proxy server hosts the mta-sts.txt file (as well as z-push) with its own Letsencrypt certificate

Therefore my plan is use the same certificate both on MTA-STS.txt web server as well as on the Zimbra (MX server) so that both respond with the same SSL certificate name (I will try to rework the script from JDunphy)

Not sure if it matters that my Zimbra server is sending via an authenticated SMTP relay service, and not directly to the internet?

(DNS name typo error has been corrected!)

I will try to align the certificate names and post the results, thank you
User avatar
rleiker
Advanced member
Advanced member
Posts: 149
Joined: Tue Jan 07, 2020 8:23 pm
Location: Kansas City
Contact:

Re: MTA-STS email security

Post by rleiker »

milauria wrote:Actually my Zimbra server runs behind a reverse proxy and has its own self-signed certificate. While the reverse proxy server hosts the mta-sts.txt file (as well as z-push) with its own Letsencrypt certificate

Therefore my plan is use the same certificate both on MTA-STS.txt web server as well as on the Zimbra (MX server) so that both respond with the same SSL certificate name (I will try to rework the script from JDunphy)
The reverse proxy setup described should work fine, so long as when an email sender requests your mta-sts.txt file from the web site, running on your reverse proxy server, the requester always receives an SSL certificate issued from a CA (certificate authority) and not a self-signed certificate with TLSv1.2 or TLSv1.3.

While not required for the MTA-STS setup you are working on now, it will be in your best interest to replace the self-signed SSL certificate on your Zimbra server, behind the proxy, with a CA issued certificate too. Zimbra does not yet support MTA-STS for outbound email, but there are other benefits to using a CA issued certificate for your outbound email too, aside from MTA-STS.

Also keep in mind that a wildcard SSL certificate is perfectly ok too for MTA-STS. So, the "Issued To" and SANs in your certificate do not need to explicitly contain mta-sts.yourdomain.com, so long as a wildcard pattern in the SSL certificate's "Issued To" contains something like: *.yourdomain.com, as this pattern would match mta-sts.yourdomain.com too.

milauria wrote:Not sure if it matters that my Zimbra server is sending via an authenticated SMTP relay service, and not directly to the internet?
For MTA-STS, this would not matter, but it would matter however for your SPF record. So in this case, you would need to list the IP address of the SMTP relay service you are using in your SPF record, but not the IPs of your Zimbra server or reverse proxy servers, since they are not directly sending email to other email servers on the Internet.
milauria
Advanced member
Advanced member
Posts: 96
Joined: Mon Aug 15, 2016 12:32 pm

Re: MTA-STS email security

Post by milauria »

Hello, I made it work by having the wildcard certificate configured on both the reverse-proxy server (where the MTA_STS.txt is located) as well as on the Zimbra server. To achieve this I have created the letsencrypt wildcard certificate on the reverse proxy server using cerbot, I created the certificate chain and copied it to the Zimbra server and deployed per Wiki from Barry … worked perfectly.

From google I receive the daily report saying “all ok”, from Microsoft I stopped receiving reports, not sure if MS sends the report only in case of errors. To check it, I sent an email from Gmail to my Zimbra and noticed that message raw text contains a TLS 1.2 encryption, so I guess all good.

One aspects on MTA-STS that I did not understand from the webinar is if the enforcing of the MTA-STS encryption risks to stop my server from receiving emails from servers that don't have TLS enabled and will generate email error to the senders.
In other words what happens if a sending mail server is unable to encrypt while the receiving servers enforces MTA_STS ?
I understand that STARTTLS is advertised from the receiver to the sender as opportunistic, and if not enabled the message defaults to plain text. Is MTS-STS also opportunistic ?

I was puzzled by the statement
Zimbra does not yet support MTA-STS for outbound email, but there are other benefits to using a CA issued certificate for your outbound email too, aside from MTA-STS.

which tells me that my Zimbra server can receive but can't send to mail servers that are enforcing MTA-STS ? Are there drawbacks of using MTA-STS ?
Thanks a lot for the clarifications so far
User avatar
rleiker
Advanced member
Advanced member
Posts: 149
Joined: Tue Jan 07, 2020 8:23 pm
Location: Kansas City
Contact:

Re: MTA-STS email security

Post by rleiker »

milauria wrote:From google I receive the daily report saying “all ok”, from Microsoft I stopped receiving reports, not sure if MS sends the report only in case of errors.
Recall from the webinar that you will only receive a daily TLS-RPT from a sender when that sender has sent email to your server in the last 24 hours. If you have not received any TLS-PRTs from Microsoft recently, it likely means that Microsoft's email servers have not sent you any email recently.
milauria wrote:One aspects on MTA-STS that I did not understand from the webinar is if the enforcing of the MTA-STS encryption risks to stop my server from receiving emails from servers that don't have TLS enabled and will generate email error to the senders. In other words what happens if a sending mail server is unable to encrypt while the receiving servers enforces MTA_STS ?
I understand that STARTTLS is advertised from the receiver to the sender as opportunistic, and if not enabled the message defaults to plain text. Is MTS-STS also opportunistic ?
To clarify on this, there are two scenarios:

Scenario 1.) An email sender that supports MTA-STS
Scenario 2.) An email sender that does not support MTA-STS

For Scenario # 1, the first time that a sender does an email delivery to your email server, they will check to see if you have an MTA-STS DNS record setup. If they find one, they will then retrieve your mta-sts.txt file from your web server & cache it according to the max_age setting you use in the mta-sts.txt file. If they later come back & do another email delivery, and an encrypted connection to your server (STARTTLS) is either not offered, or somehow blocked, then the email delivery will temporarily fail. The sender will re-try delivery a few more times, and if those attempts also fail to use encryption (STARTTLS), then the email bounces to the sender as undeliverable. This would then appear in your TLS-RPT you receive from the sender, as a heads-up that something is wrong, such as a configuration problem, or a man-in-the-middle attack that is underway.

For Scenario # 2, when a sender does not support MTA-STS, they will instead only do the standard DNS MX record look-up, and the MTA-STS DNS record will be ignored. Next, when the sender connects to your email server to do the delivery, your email server will still advertise that STARTTLS is available, but it would be at the discretion of the sender if they choose to bring up an encrypted connection at that point, or continue to deliver the email as plain-text. This would be the opportunistic encryption part. Either way, the sender will still deliver the email.

So in summary, the only occasion where MTA-STS would prevent an email delivery is when an email sender supports MTA-STS and at least one of the following is true:

1.) The sender was blocked from establishing an encrypted connection to your server for an email delivery.
2.) The email server in your DNS MX record or the web server where your mta-sts.txt file is located does not support TLSv1.2 or TLSv1.3.
3.) The host name used in your DNS MX record does not match the host name in the SSL certificate of your email server, or the mta-sts.(yourdomain) DNS A record does not match the SSL certificate host name on your web server.
4.) The SSL certificate on your email server or the web server hosting the mta-sts.txt file is expired or is using the incorrect intermediate/root certificate chain.

You would want email delivery to fail for any of the above reasons, as it indicates that something is wrong and needs immediate attention so that the confidentiality of your email is not compromised or tampered with. This is fundamentally what the MTA-STS standard's purpose is to accomplish.

In an upcoming email security webinar, the DANE standard will be discussed too, and DANE uses a similar, but even more robust method for ensuring emails are delivered using encryption. You will want to use both MTA-STS and DANE, as senders may support one or the other, or perhaps both.
milauria wrote:I was puzzled by the statement
Zimbra does not yet support MTA-STS for outbound email, but there are other benefits to using a CA issued certificate for your outbound email too, aside from MTA-STS.

which tells me that my Zimbra server can receive but can't send to mail servers that are enforcing MTA-STS ? Are there drawbacks of using MTA-STS ?
That is partially correct. As it stands today in Zimbra 8.8.15 and 9.0, both Open Source & Network Editions, they do not yet have support built-in to enforce MTA-STS for outbound email deliveries. However, you can immediately use MTA-STS to enforce encryption for your inbound email deliveries, and you should, for the reasons discussed in the webinar. When your Zimbra server makes an outbound email delivery to another server somewhere on the Internet, your Zimbra server will behave like Scenario # 2 described above. Hopefully, we will see MTA-STS support for outbound email added to an upcoming Zimbra version release so MTA-STS enforcement is in place for both inbound & outbound email.
Post Reply