By the mid-2010s, the web had largely accepted that cleartext HTTP was a mistake. Email, however, was still living in 1995. Your mail client would happily connect to your provider over port 143 (IMAP), port 110 (POP3), or port 587 (submission), attempt a STARTTLS upgrade, and — if a middlebox stripped the capability — silently fall back to sending your password in the clear. RFC 8314 is the standards-track document that finally said: stop doing that.

The core problem. The original "opportunistic TLS" model relied on STARTTLS: connect in cleartext, negotiate an upgrade, then send credentials. Two things went wrong:

• STRIPTLS attacks. An active attacker (or a broken NAT, or an overzealous ISP) could scrub the STARTTLS capability advertisement from the server greeting. The client, seeing no TLS option, would proceed in cleartext.
• Certificate validation was optional in practice. Many clients accepted self-signed or mismatched certs to "just work," making MITM trivial.

What RFC 8314 mandates. The document rehabilitates the older "Implicit TLS" model — start the TLS handshake immediately on connect, no negotiation — and elevates it to the recommended default:

• Port 465 is officially reclaimed for SMTP submission over Implicit TLS. This port had a strange history: IANA assigned it to SMTPS in 1997, revoked it in 1998 in favor of STARTTLS on 587, but the industry never stopped using it. RFC 8314 formally un-deprecated it.
• Port 993 (IMAPS) and port 995 (POP3S) are the mandated defaults for mail access.
• Ports 143, 110, and 587 may still exist, but MUAs SHOULD prefer implicit TLS ports and MUST NOT send credentials over cleartext.
• Certificate validation is mandatory. No more silent acceptance of bad certs.
• TLS 1.2 or later is required; SSLv3 and TLS 1.0 are forbidden.

The politically interesting bit. RFC 8314 explicitly acknowledges that the IETF got the port-465 story wrong. The 1998 deprecation was driven by an aesthetic preference for a single port per protocol with negotiated upgrade — an elegant idea that the deployed world rejected. Twenty years of Gmail, Outlook, and every mobile mail client using 465 anyway forced the standards body to concede. It is a rare, honest admission that operational reality can overrule protocol elegance.

Why this matters to you today. If you have ever configured a mail client, an SMTP library, or a transactional email service (SendGrid, Postmark, SES), you have chosen between port 587 with STARTTLS and port 465 with implicit TLS. RFC 8314 is why 465 is now the recommended answer. It is also why your mail library probably rejects a self-signed cert by default — behavior that would have been considered user-hostile in 2005.

The submission-vs-relay distinction still matters. RFC 8314 covers submission (user → their provider) and access (user reading mail). It does not govern MTA-to-MTA relay on port 25, which remains stubbornly opportunistic — that gap was later plugged by MTA-STS (RFC 8461) and DANE. Server-to-server email encryption is a separate, still-unfinished story.

A quiet cultural shift. RFC 8314 is short, prescriptive, and almost entirely made of "MUST" and "MUST NOT." It reads less like a protocol design and more like an intervention — the IETF telling its own community that pragmatism had beaten purity, and the sooner cleartext credentials disappeared, the better.