Ref: https://security.googleblog.com/2019/04 ... h-mta.htmlA 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.
MTA-STS email security
- JDunphy
- 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
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.
- pup_seba
- Outstanding Member
- Posts: 687
- Joined: Sat Sep 13, 2014 2:43 am
- Location: Tarragona - Spain
- Contact:
Re: MTA-STS email security
We need a "thumbs up" in this forum Thanks for the heads up!
Re: MTA-STS email security
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
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
- andras0602
- Advanced member
- Posts: 62
- Joined: Sat May 21, 2022 3:11 pm
- ZCS/ZD Version: 8.8.15
Re: MTA-STS email security
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* ?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
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.
Re: MTA-STS email security
You are right, sorry for not being precise.
The SSL checker online says this (do you need to see more details from the certificate?)
the policy file can be queried pointing the browser at: https://mta-sts.mydomain.it/.well-known/mta-sts.txt
The DNS records for mydomain.it includes:
Have I misconfigured something ? I am on ZCS OSE 8.8.15 with always latest patches installed on Centos 7
Many thanks
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
Code: Select all
version: STSv1
mode: testing
mx: mail.mydomain.it
max_age: 31557600
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.
Many thanks
Re: MTA-STS email security
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:
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:
needs to be (missing semicolon):
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
}
]
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.
Code: Select all
_mta-sts 10800 IN TXT "v=STSv1; id=2022051601"
Code: Select all
_mta-sts 10800 IN TXT "v=STSv1; id=2022051601;"
Re: MTA-STS email security
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
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
Re: MTA-STS email security
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.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)
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.
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 wrote:Not sure if it matters that my Zimbra server is sending via an authenticated SMTP relay service, and not directly to the internet?
Re: MTA-STS email security
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
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
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
Re: MTA-STS email security
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: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 clarify on this, there are two scenarios: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 ?
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.
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.milauria wrote:I was puzzled by the statementZimbra 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 ?