SMTPS (implicit SSL) has been deprecated/obsolete since SMTP+STARTTLS (explicit SSL) was defined in RFC2487. I'm not entirely clear on the reasoning behind that, but it was clearly considered a good idea at the time.

A parallel can be seen with IMAP and POP3, using port 143 for IMAP+STARTSSL vs port 993 for IMAPS, and port 110 for POP3+STARTTLS vs port 995 for POP3S.

Since these protocols differ in the same way as the SMTP encryption options, why are these implicit SSL options not deprecated in the same way?

That said, I don't see why explicit STARTTLS should be considered a better option anyway - surely it's better to start encryption as soon as possible, and STARTTLS doesn't do that, so surely implicitly encrypted services are preferable? It appears I'm not alone in this thinking, as there is an internet draft suggesting exactly this.

The only upside of explicit encryption I can see is that you can run cleartext services on the same port - but that doesn't seem like something we should encourage or continue to support if it can be avoided.

What is the rationale behind all this?

  • 1
    Funfact: A man-in-the-middle attacker can also strip the STARTTLS message and force cleartext transmission.
    – SEJPM
    Sep 21 '17 at 14:26
  • Exactly why I think all should be implicit - I just wondered why there was such a push against it in the past.
    – Synchro
    Sep 21 '17 at 14:28
  • Maybe it was the same justification as the resistance against HTTPS: CPU power.
    – ErvalhouS
    Jan 17 '18 at 23:02


  1. Because neither implicit nor explicit TLS is technically that bad;
  2. Because changing ways the Internet works takes time.

This is essentially not one, but two different questions, and I'll address them separately.

1. Why are common services using implicit SSL not considered obsolete?

As you may have already noticed, in recent years, large corporations such as Google or Facebook have put a lot of effort in securing HTTP communications, and largely succeeded at that. But one of the main drivers for that seem to be ISPs replacing Web ads with their own, which severily harms Google's and others' business models.

By the way, the implied consequences of this are huge, the very structure of the Internet is going to change a lot as the result. Geoff Huston from APNIC has summed it up in his excellent blog post and related presentations (slides, video), so I'd better just refer to that without explaining it further here.

There are, of course, other drivers as well, but a lot of them are still heavily bound to securing someone's business models (e.g. PCI SSC activities and so on).

What's most important here is though those achievements in HTTP area raise a bar pretty high, many other ways of communication, including e-mail, seem to lack that sort of commercial drivers HTTP luckily has, and this is probably one of the main reasons their security stays rather obsolete, compared to what we have currently in HTTP. As the result, in 2018, it's still necessary to support a great number of outdated mail access servers, user and transfer agents which are only able to communicate in cleartext.

Hopefully this will change, but I personally can currently offer no clear estimations for that.

Both implicit and explicit TLS approaches are better than cleartext, as securing communication either way is better than not securing it at all. Some MUAs and MTAs deployments out there only support either implicit or explicit TLS, and deprecating any of the concepts leaves those deployments without any countermeasures against MitM attacks. Deprecating protocols and methods that are used actively on the Internet — and are essentially better than nothing — in favor of nothing is a bad practice.

As you can see, deprecating SMTPS alone haven't done us any good: it's still there in the wild. This is an example that a widely used Internet protocol couldn't be just shut down at will. Right, sounds funny, but back in circa 1998 when it happened it might have been less clear than it is today.

Moreover, declaring one of the concepts outdated in favor of the other must be supported by the Internet community, and though most people agree there should be only one of two options left as preferred at the end of the day, it's not that easy to reach consensus on whether explicit TLS is better or not (more on that below). The Internet draft you're pointing to is a fundamental initiative towards bringing a piece of sanity in all this mess without bringing up a common standards dilemma:

XKCD: Standards

Once it's finalized, a process of explicit TLS deprecation would start at some point in future, but it will take time.

2. Why explicit STARTTLS should be considered a better option?

A disclaimer: this is simply an outline of current approaches towards the Internet protocol design. I'm not taking sides here, the right places for objections against those approaches are IETF working group mailing lists and meetings.

Implicit TLS is great for protocols which are designed from scratch, with contemporary threat models in mind, and which lack the requirement to support cleartext communication. However, implicit TLS is somewhat a controversial approach with regard to securing old cleartext protocols. It seems to be working fine for HTTPS, but it required some effort, including allocation of a different port (443) for secure HTTP communications.

The downside of this approach is that for each remaining cleartext protocol, you'll need to allocate another TCP/UDP port, while the global TCP port space is severily limited. At some point, IETF working groups generally considered wasting ports this way a bad practice, and even port 465 (originally SMTPS) was later reallocated for a different purpose (this actually happened about 20 years ago, which as well sheds some light on how slowly the Internet adopts changes).

Again, as you can see in draft-ietf-uta-email-deep, this consideration might be withdrawn in the near future. Note also that this draft originally dates back to year 2013 and is now only approaching the final state, which gives you an idea of how hard this choice is overall.

The general idea of opportunistic (or explicit) TLS is to somehow inform a client in advance (using a different communication channel, already verified before and thus trusted) that a particular remote server supports STARTTLS, so the client must only use STARTTLS for data transfer towards that server, thus preventing STRIPTLS attacks. Originally DNSSEC was supposed to provide this separate channel, however, its worldwide deployment has somehow stalled, and as the result, working groups are considering other ways (e.g. TOFU) to do that.

Note that the implicit approach itself is not downgrade-resistant as well, as a man in the middle is able to strip implicit TLS. Approaches like HSTS depend on TOFU themselves. A common argument is that a user can force their software client into secure communication by explicitly specifying a port number in client preferences, but a software client can also provide user with an ability to explicitly enforce STARTTLS on an old port, so from the user's perspective the difference between two approaches is subtle.


Port 465 has been un-obsoleted

As per Wikipedia: https://en.wikipedia.org/wiki/SMTPS:

RFC 8314 "Cleartext Considered Obsolete: Use of TLS for Email Submission and Access" reinstates the registration of port 465 for implicitly encrypted mail submission.

Specifically: https://www.rfc-editor.org/rfc/rfc8314#section-3.3 (From January 2018.)

  • Not only that, but Implicit TLS is now the recommendation! "… this specification now recommends the use of Implicit TLS for POP, IMAP, SMTP Submission".
    – Kal
    Sep 17 '20 at 1:58
  • This isn't strictly accurate. SMTPS has not been undeprecated. What has happened is that RFC8314 provided a new definition of the SMTP submission protocol over implicit TLS on port 465. By a stroke of luck, most of the implementations of SMTPS (which has looser requirements than SMTP submission) were also compatible with this new definition, so the net result is the same and the difference is (thankfully) academic.
    – Synchro
    Jun 10 at 7:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.