There's often quite a bit of confusion around the different terms SSL, TLS and STARTTLS.

SSL and TLS both provide a way to encrypt a communication channel between two computers (e.g. your computer and our server). TLS is the successor to SSL and the terms SSL and TLS are used interchangeably unless you're referring to a specific version.

STARTTLS is a way to take an existing insecure connection and upgrade it to a secure connection using SSL/TLS. Note that despite having TLS in the name, STARTTLS doesn't mean you have to use TLS. You can still use SSL.

SSL/TLS version numbers

Version numbering is inconsistent between SSL and TLS versions. When TLS took over from SSL as the preferred protocol name, it began a new version number, and also began using sub-versions. So the ordering of protocols in terms of oldest to newest is:

  1. SSL v2,
  2. SSL v3,
  3. TLS v1.0,
  4. TLS v1.1,
  5. TLS v1.2,
  6. TLS v1.3.

When you connect to an SSL/TLS encrypted port, or use STARTTLS to upgrade an existing connection, both sides will negotiate which protocol and which version to use based on what has been configured in the software and what each side supports.

Support for SSL/TLS is virtually universal these days, however which versions are supported is variable. As of May 2018, SSL v2 and SSL v3 were deprecated and have been phased out due to security issues. Almost all software supports TLS v1.0, TLS v1.1 and TLS v1.2, and many sites and services now strongly recommend at least TLS v1.2 for its overall improved security profile.

TLS vs STARTTLS naming problem

One cause of confusion is that some email software incorrectly uses the term TLS when they should have used STARTTLS. Older versions of Thunderbird in particular used "TLS" to mean that STARTTLS should be used to upgrade the connection, and the connection should fail if STARTTLS is not supported. These versions also used the term "TLS, if available" to mean try to use STARTTLS to upgrade the connection if the server has support for it, otherwise use an insecure connection.

SSL/TLS vs plaintext/STARTTLS port numbers

The confusion surrounding these terms can cause particular problems when the user must configure a port number for each protocol.

To add security to some existing protocols (for example IMAP, POP, and others), it was decided to just add SSL/TLS encryption as a layer underneath the existing protocol. However, to distinguish that software should use the SSL/TLS encrypted version of the protocol (implicit TLS) rather than the plaintext one, a different port number was used for each protocol. So you have:

At some point, it was decided that having 2 ports for every protocol was wasteful, and instead you should have 1 port that starts off as plaintext, but the client can upgrade the connection to an SSL/TLS encrypted one. This is what STARTTLS was created to do.

There were a few problems with this though. There was already existing software that used the alternate port numbers with pure SSL/TLS connections. Client software can be very long lived, so you can't just disable the encrypted ports until all software has been upgraded.

Mechanisms were added to each protocol to tell clients that the plaintext protocol supported upgrading to SSL/TLS (i.e. STARTTLS), and that they should not attempt to log in without doing the STARTTLS upgrade. This created two unfortunate situations:

  1. Some software just ignored the "login disabled until upgraded" announcement and just tried to log in anyway, sending the username and password over plaintext. Even if the server then rejected the login, the details had already been sent over the Internet in plaintext.
  2. Other software saw the "login disabled until upgraded" announcement, but then wouldn't upgrade the connection automatically, and thus reported login errors back to the user, which caused confusion about what was wrong.

Both of these problems resulted in significant compatibility issues with existing clients, and so most system administrators continued to just use plaintext connections on one port number, and implicit encrypted connections on a separate port number.

This has now basically become the de facto standard that everyone uses. IMAP SSL/TLS encrypted over port 993 or POP SSL/TLS encrypted over port 995. Many sites (including Fastmail) now disable plain IMAP (port 143) and plain POP (port 110) altogether so people must use an SSL/TLS encrypted connection. By disabling ports 143 and 110, this completely removes STARTTLS as even an option for IMAP/POP connections.

SMTP STARTTLS as an exception

The one real exception to the above is SMTP. However that's for a different reason again. Most email software (known as a mail user agent) used SMTP on port 25 to submit messages to the email server for onward transmission to the destination (known as a mail transfer agent). However, SMTP was originally designed for transfer, not submission. So yet another port (587) was defined for message submission.

Although port 587 doesn't mandate requiring STARTTLS, the use of port 587 became popular around the same time as the realisation that SSL/TLS encryption of communications between clients and servers was an important security and privacy issue and encryption extensions were being defined for SMTP. So shortly after port 465 was defined, it was revoked with the expectation that clients would move to using STARTTLS over port 587.

The result is that in most cases, systems that offer message submission over port 587 require clients to use STARTTLS to upgrade the connection and also require a username and password to authenticate. There has been an added benefit to this approach as well. By moving users away from using port 25 for email submission, ISPs are now able to block outgoing port 25 connections from users' computers, which were a significant source of spam due to infection with spam-sending viruses.

Unfortunately the downside of changing port numbers is that a number of email clients were made which only supported implicit SSL/TLS over port 465 and not STARTTLS on 587. Clients are often very long lived, and so removing port 465 wasn't an option for many sites without annoying customers. Additionally, because port 465 was advertised as an option, many users with email clients that support both STARTTLS on 587 and SSL/TLS on 465 set them up to use 465 instead of 587. This makes it even harder to remove support for port 465, since lots of users have their email clients set up to use it.

Currently, things seem relatively randomly split between people using SMTP SSL/TLS encrypted over port 465, and people using SMTP with STARTTLS upgrading over port 587.

And just to add extra confusion, in 2018 it was decided to change yet again, and recommend using implicit TLS over port 465 to "encourage more widespread use of TLS and to also encourage greater consistency regarding how TLS is used, this specification now recommends the use of Implicit TLS for POP, IMAP, SMTP Submission, and all other protocols used between an MUA and an MSP."

Again, given the very long life of client software, it's likely to take decades before port 587 can be discontinued, so we'll continue offering both implicit TLS over port 465 and opportunistic STARTTLS over port 587 for the foreseeable future.