I think the warning is just incorrect. Servers will negotiate to the highest encryption level available, and there is more to the encryption stack than just TLS versions. If your servers talk TLS1.2 and older versions, devices that requires TLS1.2 will connect with TLS1.2, and devices that cannot use TLS1.2 will negotiate down to an earlier version. I have no theory or evidence that running TLS1.0 creates an interoperability problem.
It DOES create a policy problem. For example, PCI DSS scanners will throw a tantrum when they see TLS1.0, and your ability to negotiate an exception may be limited.
Let's examine the vulnerabilities:
1) For encryption to be useful, you must know that you are talking to the correct endpoint. If a malicious router has diverted your traffic to a rogue server, encrypting the session with that server is useless. The only way to have certain identity for outbound mail is to require verification of the server certificate. SM cannot do this at present. My untested expectation is that many destination servers use self-signed or expired certificates, and if you refuse to talk to them you will have more problems than you can handle.
2) TLS1.0 and TLS1.1 are vulnerable to a two-stage attack, where a man-in-the-middle first tricks both ends to downgrade from TLS1.2, then uses additional tricks to decrypt the traffic between them. If you use Kyle's suggestion, you have not solved the problem. If the man-in-the-middle attacker blocks the TLS1.2 connection to the first gateway, when the connection is retried on the second gateway his downgrade attack will proceed as originally planned. Of course, traffic interception only matters for messages that are "imporant", which is in the eye of the beholder. In general, intercepted data becomes more useful as the volume increases, even if each individual message is low risk.
3) If you require either or both certificate verification and TLS1.2, your fallback options are limited when there is a failure.
(a) You can use no encryption, which simplifies both types of attacks because you cannot verify the remote server identity and you cannot prevent interception (or even manipulation) by a middleman.
(b) You can refuse to send or receive with the domains that cannot do TLS1.2.
(c) You can use end-to-end encryption like S/MIME or PGP, in which case the transport layer does not matter, but the other user must also be able to handle those methods.
Security talks about Confidentiality, Integrity, and Availability. Certificate verification and TLS1.2 improve confidentiality and integrity, but they damage availability. So it is a policy call.
Our solution has been to use a third-party outbound gateway that can do web relay. We require TLS on all outbound connections. Domains that cannot do any encryption are added to a list which activates web relay for any traffic to that domain. It reduces our corporate risk if an employee sends regulated content through email. For inbound messages, we still accept unencrypted, but we are not in Europe and not subject to GDPR.
I strongly believe in using an Inbound Gateway to distinguish between unauthenticated SMTP from the Internet and authenticated SMTP from email clients. Then you add Declude to both servers, because it will log the Received header (including encryption details) for each message (depending on log level selection). Then you parse the Declude logs to detect who is and is not using TLS1.2. There are other benefits to having this separation of duties:
- spam filtering configuration is likely to be very different between Internet sources and client sources. You don't need to worry about SPF, DMARC, etc for authenticated users.
- Attempts to use authenticated SMTP on an incoming gateway can be used as a honeytrap to detect and block hostile servers (see my post about this).
I am sure there are others