Mimecast and their broken TLS

You might have been redirected here because you are using the Mimecast services
and your mail was rejected by a mail server of samba.org due to a bug in
Mimecast's TLS handshake with other mail servers.

In August 2021 we looked into implementing stricter TLS checks on our mail
servers, which includes checking of server name indication (SNI) of incoming
SMTP TLS connections. We noticed from one provider (Mimecast) invalid SNI names
being sent. We contacted them via support@mimecast.com but never got a reply,
except for an auto-reply, pointing to their portal, where only registered
customers can communicate with them.

As they ignored our mail we added the SNI check in late 2021. As a result
senders from Mimecast servers get an error message, saying that they should
contact their mail server admins to fix the wrong SNI.

One of their customers contacted us and told us about their mail delivery
problem. We told them, that they should contact Mimecast to fix this problem.
As a paying customer they were able to talk to them and get a reply, so we
could talk a little to Mimecast proxied through their customer at least here
:-).

The issue is that the SNI needs to match the hostname of the MX record of the
receiving domain, in our case this is for example smtp.samba.org

What Mimecast does though is, they send the name of the hostname that the MTA
reports back (which is not necessarily the same as the name of the MX record).
We explained that this is _wrong_ and that the MX name _must_ be used. They
replied back to their customer that we would have to fix our server and
justified, that sending hr2.samba.org as SNI would be correct because this is
the name that the MTA reports back in the HELO/EHLO banner.

People who are familiar with the anatomy of man in the middle attacks (MITM)
will notice that requesting/expecting a TLS certificate based of the host name
that the receiving MTA sends in the EHLO banner is not a good idea. Apart of
that it's quite well known, that SNIs should not depend on reverse DNS
resolutions or on hostnames that a server claims to have in a previous
plaintext chat.  It's surprising to us that Mimecast, who sell their mail
service as a security feature do not see that and that they don't admit to
their customers that their service needs a fix but instead ask their customers
to ask other people to weaken their TLS checks.

That being said also remember that Mimecast, who should make your mail
communication more secure, let hackers spy on their customers' mail earlier the
same year:

https://www.reuters.com/article/us-global-cyber-mimecast-idUSKBN29H22K

Taking that and our above described experience into account, we can only
recommend better not to rely on Mimecast services.

In the year 2022 we would also not recommend using a service that promises
security but that neither supports IPv6, TLS 1.3, DANE nor DNSSEC. All of this
is state of the art these days.

2022-01-10
postmaster@samba.org