The specification sequence Is SSL2.0 -> SSL3.0 -> TLS 1.0 > TLS 1.1 -> TLS 1.2 -> TLS 1.3
Systems negotiate to the highest protocol that is mutually supported.
Most systems have SSL 2.0 disabled as it was never widely implemented and it has significant security issues.
TLS 1.3 is the newest and I don't know of any version of Windows that has it implemented (but could be uninformed.)
SSL3.0, TLS1.0, and TLS1.1 are deprecated because of potential vulnerabilities that have been detected by white-hat researchers and might be exploited by very sophisticated attackers (such as nation-state actors.) Part of the attack is to trick TLS 1.2-capable systems to fall back to the earlier and weaker protocols, so there is pressure (especailly from PCI DSS) to disable earlier protocols so that they will never be used, even as a fallback. Any reasonable client should be able to support TLS 1.2, so this should not be an obstacle for your most desktop users. (Windows XP supported it with an optional Windows Update kit. Early versions of Windows 7 had it available but disabled b y default. It was subsequently enabled by default by a Windows Update.)
TLS 1.0 and later support "STARTTLS", which allows the client to start in non-encrypted mode and switch to encrypted mode. SSL 3.0 does not have that capability.
What I understand all of this to mean:
For client connections using SMTP, IMAP, and POP:
- If your SmarterMail port definition is SSL, your clients must connect with encryption. You can adjust your server settings to control which protocols you will accept.
- If your SmarterMail port definition is TLS, your clients can use either unencrypted or encrypted sessions. You can till adjust your server settings to control which protocols are accepted.
Awhile back, I switched from SSL to TLS in my port definitions, but based on the above, I am debating whetehr to switch back.
Caveats:
Things get more complicated if you do not have an incoming gateway, because now you have to worry about the encryption capabilities of remote systems. My observation is that there are still remote systems which cannot do encryption or cannot do TLS1.2, even though their message traffic is acceptable. Consequently, my incoming gateway still allows weak TLS 1.0 and TLS 1.1 protocols as well as unencrypted connections. Currently arguing the point with my PCI DSS scan company.
If you do not have an incoming gateway, I encourage you to implement one. This allows you security policies for unauthenticated inbound mail connections that is different from authenticated email client connections