What this RFC defined
RFC 2595 defined how to use TLS with IMAP, POP3, and ACAP protocols by adding a STARTTLS upgrade mechanism to each. It was the first specification for encrypting these email access protocols, preceding the modern approach that uses implicit TLS on dedicated secure ports (993 for IMAP, 995 for POP3).
Where you would have seen it in practice
RFC 2595 introduced the STLS command for POP3 and the STARTTLS capability for IMAP, allowing existing connections on ports 143 and 110 to upgrade to TLS before authentication. This was a significant security improvement over cleartext credentials. The STARTTLS approach it defined is still widely deployed in legacy configurations.
How it connects to other RFCs
RFC 2595 was obsoleted by RFC 8314, which mandates implicit TLS and deprecates the STARTTLS upgrade for client-to-server connections. It predates RFC 5246 (TLS 1.2) and RFC 8446 (TLS 1.3). The STLS and STARTTLS commands it defined remain present in deployed infrastructure but RFC 8314 is the current security requirement.
Current status
RFC 2595 was obsoleted by RFC 8314 in 2018. RFC 8314 deprecates the STARTTLS upgrade approach for client submission and access in favour of implicit TLS on dedicated secure ports. Legacy configurations using STARTTLS on ports 143 and 110 still follow RFC 2595 patterns, but new deployments should follow RFC 8314 and use ports 993 and 995.
STARTTLS for IMAP and POP3
RFC 2595 defined STARTTLS-style upgrades for IMAP, POP3, and ACAP in June 1999. The mechanism follows the same design as SMTP STARTTLS (RFC 3207): a client connects on the standard cleartext port (143 for IMAP, 110 for POP3), the server advertises STLS or STARTTLS capability, the client issues the upgrade command, and both sides negotiate TLS in place. This design allowed the same port to serve both cleartext and encrypted sessions during the transition period from insecure to secure defaults.
Superseded by RFC 8314
RFC 2595 was effectively superseded by RFC 8314 in January 2018. RFC 8314 declared cleartext mail submission and retrieval obsolete and recommended implicit TLS on dedicated ports (993 for IMAP, 995 for POP3) as the modern default. STARTTLS on the legacy cleartext ports still works, but new deployments should prefer implicit TLS to eliminate the downgrade window during which STARTTLS negotiation happens over plaintext.
The stripping attack
Like SMTP STARTTLS, IMAP and POP3 STARTTLS are vulnerable to stripping attacks where a network-level attacker removes the STLS capability from the server response, forcing the client to remain on cleartext. This is why RFC 8314 recommends implicit TLS: connecting to port 993 immediately negotiates TLS with no cleartext window at all. Clients that fall back gracefully from implicit TLS to STARTTLS on the legacy port defeat the purpose of implicit TLS; the client should refuse to connect if implicit TLS fails on the dedicated port.
RFC 2595 (June 1999) defines Using TLS with IMAP, POP3, and ACAP: how these mail access protocols upgrade to TLS via the STARTTLS command, analogous to RFC 3207 for SMTP. Introduces the STARTTLS command for IMAP (port 143) and STLS for POP3 (port 110). Alternative to implicit TLS on the dedicated ports (993 for IMAP, 995 for POP3). Extended and hardened by RFC 8314, which recommends implicit TLS over STARTTLS for new deployments.
RFC 2595 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Upgrade IMAP, POP3, and ACAP client-server sessions to TLS |
| IMAP command | STARTTLS on port 143 |
| POP3 command | STLS on port 110 |
| Advertisement | IMAP: STARTTLS in CAPABILITY; POP3: STLS in CAPA |
| Alternative | Implicit TLS: IMAP on 993, POP3 on 995 (started with TLS from first byte) |
| Published | June 1999 |
| Modernization | RFC 8314 (2018) recommends implicit TLS for new deployments |
STARTTLS across IMAP, POP3, and SMTP
| Protocol | STARTTLS command | Cleartext port | Implicit TLS port | Governing RFC |
|---|---|---|---|---|
| SMTP submission | STARTTLS | 587 (and 25 for relay) | 465 | RFC 3207 |
| IMAP | STARTTLS | 143 | 993 | RFC 2595 |
| POP3 | STLS | 110 | 995 | RFC 2595 |
IMAP STARTTLS dialogue
POP3 STLS dialogue
Common IMAP/POP3 TLS mistakes
disable_plaintext_auth = yes.Related standards and further reading
- RFC 3501: IMAP4rev1 (current IMAP)
- RFC 9051: IMAP4rev2 (2021 update, incremental adoption)
- RFC 1939: POP3
- RFC 4954: SMTP AUTH (analogous pattern for SMTP)
- SSL/TLS Email Setup Guide: practical TLS configuration
- Email Protocols and Ports Guide: 993/995 vs 143/110
Frequently asked questions
Should I use STARTTLS on port 143/110 or implicit TLS on port 993/995?
Per RFC 8314, prefer implicit TLS (993 for IMAP, 995 for POP3) for new deployments. Reasons: eliminates the pre-upgrade cleartext window that STARTTLS on 143/110 has, simpler client logic (no capability negotiation dance), and no fallback path for downgrade attacks. Servers should offer both to maintain compatibility with existing clients. Modern email clients default to implicit TLS.
Why does POP3 use STLS instead of STARTTLS?
POP3 commands are typically 4-character uppercase (USER, PASS, RETR, DELE). STLS follows this pattern; STARTTLS would be an outlier. Functionally, STLS in POP3 is analogous to STARTTLS in IMAP and SMTP: upgrade an authenticated session to TLS. Same semantics, different command name.
What is LOGINDISABLED in IMAP CAPABILITY?
An advertisement telling clients “the LOGIN command is disabled at this security level.” Servers typically advertise LOGINDISABLED before STARTTLS to prevent clients from sending credentials over cleartext. After successful STARTTLS, subsequent CAPABILITY responses omit LOGINDISABLED and offer LOGIN and various AUTH mechanisms. Clients should check for LOGINDISABLED and refuse to attempt authentication when it is present.
Are IMAP and POP3 STARTTLS still relevant in 2026?
Widely deployed but less recommended for new setups. Per RFC 8314, implicit TLS on dedicated ports is preferred. However, port 143 with STARTTLS and port 110 with STLS remain functional and common in legacy configurations. Modern servers should offer both approaches; modern clients default to implicit TLS on 993/995.
Can I use TLS 1.3 with IMAP and POP3?
Yes. RFC 2595 predates TLS 1.3 but the STARTTLS mechanism is version-agnostic; the negotiated TLS version depends on what both client and server support. Modern servers (Dovecot, Cyrus) support TLS 1.3 (RFC 8446) with appropriate cipher suites. Modern clients negotiate 1.3 when both sides support it, falling back to 1.2. Disable TLS 1.0 and 1.1 per RFC 8996 deprecation.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
