IMAP vs POP3 Explained: How Mail Retrieval Works and How to Secure It

IMAP and POP3 are the standard protocols a mail client uses to read mail from a server. IMAP (version 4rev2, RFC 9051) keeps messages and folders on the server and syncs every device, while POP3 (RFC 1939) downloads messages to one client. Secure both with implicit TLS on ports 993 and 995 and token based login.

Neither protocol sends mail; that is SMTP submission on ports 587 and 465. IMAP and POP3 cover the last hop, from the mailbox to the reader, which is where a user's password has historically travelled, often from an app nobody has updated in years. This post covers both protocols on the wire, checked against the RFCs, the weakness classes as concepts, Dovecot configuration, and the checks a defender can run on their own servers.

Key takeaways

• IMAP4rev2 is RFC 9051 (August 2021), which obsoletes RFC 3501 (IMAP4rev1, March 2003). POP3 is RFC 1939 (May 1996), Internet Standard STD 53, extended by RFC 2449 (CAPA) and RFC 5034 (SASL AUTH).
• IMAP treats mailboxes as remote folders with server side flags and search. POP3 treats the mailbox as a single maildrop that the client normally downloads and then deletes.
• IMAP uses 143 (STARTTLS) and 993 (implicit TLS). POP3 uses 110 (STLS) and 995 (implicit TLS). RFC 8314 (January 2018) prefers implicit TLS and says cleartext access should be deprecated.
• OAUTHBEARER (RFC 7628, August 2015) replaces the password with an OAuth 2.0 bearer token and requires TLS. Large hosted providers have turned off password logins for IMAP and POP.
• The weakness classes are cleartext credentials, STARTTLS stripping, STARTTLS command injection (CERT/CC VU#555316, public 7 March 2011) and password spraying against protocols that cannot prompt for a second factor.
• On Dovecot 2.4: ssl = required, auth_allow_cleartext = no and ssl_min_protocol = TLSv1.2 (both defaults), with the cleartext listeners disabled.

What IMAP and POP3 are for: the layer and the standards

Both are application layer protocols over TCP, used between a Mail User Agent (the mail app) and a Mail Access Server (the server holding the mailbox), in RFC 8314's terms. Mail reaches that server over SMTP, which has its own transport security; see MTA-STS and TLS-RPT and how to set up SPF, DKIM and DMARC.

IMAP lets a client manipulate remote mailboxes in a way RFC 9051 calls "functionally equivalent to local folders": create, rename and delete mailboxes, set flags, search, fetch only the MIME parts needed, and resynchronise after being offline. RFC 9051 (August 2021, Proposed Standard) obsoletes RFC 3501 and folds in many extensions. Its abstract notes that IMAP does not post mail; that is left to a submission protocol such as RFC 6409.

POP3 is deliberately small. RFC 1939 says it is "not intended to provide extensive manipulation operations of mail on the server"; mail is normally downloaded and then deleted. There are no folders, flags or search. RFC 1939 (May 1996) obsoletes RFC 1725 and, per the RFC Editor index, has been updated by RFC 1957, RFC 2449, RFC 6186 and RFC 8314.

The shared security documents:

How IMAP works on the wire

The server listens on 143 for cleartext or 993 for implicit TLS. Everything is CRLF terminated lines, plus counted literals for long or binary data.

Tags, untagged responses and continuations

Each client command starts with a tag such as A001. The server replies with three kinds of line:

Tags let several commands be in flight at once. RFC 9051 says a client must accept any server response at all times, which is what makes push updates possible and also why a careless client can be fed responses that do not belong to its current state.

The IMAP state machine

A BYE greeting rejects the connection outright.

A full IMAP session

Simplified from RFC 9051 Section 8. Credentials and fetch output are omitted.

Client                                       Server (port 143)
  | <--- * OK [CAPABILITY STARTTLS AUTH=SCRAM-SHA-256 LOGINDISABLED IMAP4rev2] Ready
  | ---- a000 STARTTLS ------------------------> |
  | <--- a000 OK Proceed with TLS negotiation    |
  | ==== TLS handshake ========================= |
  | ---- A001 AUTHENTICATE SCRAM-SHA-256 ------> |   (base64 SASL challenge
  | <--- + (server challenge) ------------------ |    and response lines)
  | ---- (client proof) ----------------------> |
  | <--- A001 OK authentication successful       |
  | ---- babc ENABLE IMAP4rev2 ----------------> |
  | ---- a002 SELECT inbox --------------------> |
  | <--- * 18 EXISTS                             |
  | <--- * OK [UIDVALIDITY 3857529045]           |
  | <--- a002 OK [READ-WRITE] SELECT completed   |
  | ---- a003 FETCH 12 FULL -------------------> |
  | ---- a005 STORE 12 +FLAGS \Deleted --------> |
  | ---- a006 LOGOUT --------------------------> |
  | <--- * BYE server terminating connection     |
  | <--- a006 OK LOGOUT completed                |

On port 993 the STARTTLS exchange disappears: TLS starts as TCP connects.

UIDs, UIDVALIDITY and IDLE

A message sequence number is a position (1 to N) that shifts when messages are expunged. A UID is a non zero 32 bit value assigned in strictly ascending order; RFC 9051 says the UID plus the mailbox's UIDVALIDITY forms a 64 bit value that must never refer to another message in that mailbox. A client remembers the highest UID it has seen and asks for anything newer; if UIDVALIDITY changes, it discards its cache. That is what makes offline sync and multiple devices work.

IDLE (RFC 2177, June 1997, now core) gives push without polling. The client sends IDLE, the server answers +, and the server may then send EXISTS, EXPUNGE and FETCH updates at any time until the client sends DONE. RFC 9051 advises reissuing IDLE at least every 29 minutes so an inactivity timer does not log the client off.

The line format at a glance

These are text protocols, so the closest thing to a header layout is the line grammar.

How POP3 works on the wire

RFC 1939 has the server listen on TCP 110, send a greeting, and exchange commands and responses until the connection closes.

DELE only marks a message. Nothing is removed until QUIT moves the session to UPDATE. If the connection drops or the inactivity timer fires, nothing is deleted. RFC 1939 says that timer, if present, must be at least 10 minutes.

A POP3 session

Adapted from RFC 1939 Section 10 and RFC 5034 Section 6, with TLS and SASL. Credentials are omitted.

Client                                       Server (port 110)
  | <--- +OK POP3 server ready                  |
  | ---- CAPA ---------------------------------> |
  | <--- +OK ... SASL ... STLS ... .            |
  | ---- STLS ---------------------------------> |
  | <--- +OK Begin TLS negotiation              |
  | ==== TLS handshake ========================= |
  | ---- CAPA (again, now under TLS) ----------> |
  | ---- AUTH (mechanism and response) --------> |
  | <--- +OK Maildrop locked and ready          |
  | ---- STAT / RETR 1 / DELE 1 ---------------> |
  | ---- QUIT ---------------------------------> |
  | <--- +OK signing off                        |

On port 995 the STLS step disappears.

The optional UIDL command returns a unique ID per message. Clients use it for "leave messages on server", remembering which IDs they have downloaded. Each device keeps its own list and sees no folders, read status or deletions made elsewhere, which is why POP3 is a poor fit for multiple devices.

RFC 2449 added CAPA so clients stop probing. RFC 5034 defined AUTH: the client names a SASL mechanism, the server sends + challenges, the client answers in base64, and * cancels. Only one successful AUTH is allowed per session. RFC 5034 makes PLAIN over TLS mandatory to implement and requires a server configuration, which should be the default, that does not advertise or accept plaintext password mechanisms until STLS has been used.

Ports, TLS modes and IANA registrations

From the IANA service name and port registry, checked 23 October 2026:

STARTTLS and STLS (RFC 2595). The connection starts in cleartext. The client sends STARTTLS or STLS, the server says OK, and TLS starts right after that reply. Two rules carry the security weight: the client must send nothing else until TLS completes, and afterwards it must discard the capability list it saw in cleartext and ask again, because an attacker could have edited it.

Implicit TLS (RFC 8314). TLS starts as soon as TCP connects on 993 or 995, with no cleartext phase. RFC 2595 Section 7 originally discouraged these separate ports. RFC 8314 replaced that section, noting implicit TLS "has been deployed more successfully", and asks providers to offer it, keep STARTTLS only for older clients in the near term, advertise implicit TLS first in SRV records and deprecate cleartext "as soon as practicable". RFC 9051 still requires servers to implement implicit TLS and, if they listen on 143, to allow STARTTLS there.

TLS versions. RFC 9051 requires TLS 1.2 or newer and recommends TLS 1.3; with TLS 1.2, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is mandatory to implement. Clients must check the server hostname against the certificate (RFC 7817). RFC 8314 says a new account's default must require certificate validation, and clients must not offer a click through past a failed check on an existing account. For the handshake itself see TLS handshake step by step and TLS 1.3 vs TLS 1.2: what to disable.

How authentication works: LOGIN, SASL and OAUTHBEARER

IMAP has LOGIN username password; POP3 has USER then PASS. RFC 9051 says LOGIN "sends passwords in the clear", and RFC 1939 says the same of PASS. Inside TLS the network cannot read them, but the server still receives the real password, and that password still works wherever else it was reused.

POP3's APOP sends an MD5 digest of a server timestamp plus a shared secret. RFC 1939 only says it is "conjectured" to provide origin identification and replay protection. It relies on MD5 and on the server holding a usable copy of the secret. Treat it as historical.

Anything stronger goes through SASL (RFC 4422): AUTHENTICATE in IMAP, AUTH in POP3, with mechanisms advertised as AUTH=... in the IMAP capability list or on a SASL line in POP3 CAPA.

OAUTHBEARER (RFC 7628)

OAuth 2.0 defines how a client gets a token. RFC 7628 defines how the client presents it to an IMAP, POP or SMTP server through SASL: one initial response carrying the user, host, port and an auth=Bearer field with the token. On failure the server returns a JSON error with a status and, optionally, the required scope and an OpenID discovery URL, and the client sends a dummy response so the exchange can finish.

The benefit, per the abstract, is that a token has more entropy than a password, usually carries limited rights and can be revoked without a password change. The mechanism adds no security layer of its own; RFC 7628 says that "without TLS usage at the application layer, this method is completely insecure". It also warns that a long IMAP connection can outlive its token. For OAuth basics, see what is OAuth. Dovecot's OAuth2 documentation recommends oauthbearer and also supports xoauth2, an older mechanism not defined in RFC 7628.

Why mail providers are retiring basic auth passwords

"Basic auth" here means LOGIN, USER and PASS, or SASL PLAIN, with the account's real password.

Microsoft's Exchange Online documentation says Basic authentication is now disabled in all tenants for POP, IMAP and other protocols, with 1 October 2022 as the date for most cloud environments, and it can no longer be re-enabled. Its reasons: credentials are easier to capture, especially without TLS; stolen credentials get reused elsewhere; and multifactor authentication is hard or impossible to enforce while basic auth stays on. It released OAuth 2.0 support for POP, IMAP and SMTP AUTH in 2020.

Google's Workspace documentation says that from 14 March 2025 third party apps must use OAuth for Gmail, and IMAP, POP and SMTP no longer work with legacy passwords, except app passwords. New basic auth connections were blocked from summer 2024. Its stated reason is that basic authentication makes accounts more vulnerable to hijacking.

The protocol reason under both is that LOGIN and PASS have no step where a server can ask for a second factor. A password accepted over IMAP is a complete credential, and every guess gets a clean yes or no. Token login moves the interactive part, including multifactor prompts and device checks, into the provider's web sign in, and the mail protocol only sees a short lived token. RFC 9051 now says servers should analyse failed logins for brute force and password spraying, citing the UK NCSC, and must block accounts whose passwords match well known spraying lists.

Versions and history

POP3 has had no new core version since 1996 and survives because it is simple; scanners, ticketing systems and line of business apps still fetch mail with it.

RFC 9051 Appendix E lists 30 changes from RFC 3501. The ones that matter most: common extensions become core (NAMESPACE, UNSELECT, UIDPLUS, ESEARCH, ENABLE, IDLE, SASL-IR, LIST-EXTENDED, LIST-STATUS, MOVE); 64 bit message sizes; UTF-8 mailbox names and headers; CHECK removed and LSUB and \Recent deprecated; TLS guidance updated to RFC 7525, RFC 7817 and RFC 8314; new warnings about ALERT and PREAUTH; and DIGEST-MD5 replaced by SCRAM-SHA-256. Most deployed servers still speak IMAP4rev1 and offer IMAP4rev2 through ENABLE IMAP4rev2, so seeing only IMAP4rev1 in a capability list is normal.

Security properties and known weakness classes

RFC 9051 opens its security section by saying IMAP transactions, including mail, are "sent in the clear over the network" unless protection is negotiated. Neither protocol has confidentiality, integrity or server authentication of its own; all of it comes from TLS.

TLS covers only the hop to the access server, and RFC 8314 says it does not address attackers who have compromised the provider.

Cleartext credentials

On 143 or 110 without STARTTLS, LOGIN, PASS and SASL PLAIN put the password on the network. RFC 9051 requires servers to support refusing password logins until the session is protected, advertising LOGINDISABLED. The Dovecot documentation notes the gap: many clients ignore LOGINDISABLED and send the password anyway, and the server cannot stop that. The full fix is not offering a cleartext port. RFC 8314 adds that users who sent passwords in cleartext should change them when migrating, since some should be assumed compromised.

STARTTLS stripping and capability tampering

A STARTTLS session starts in cleartext, so an on path attacker can remove STARTTLS from the capability list, and a client that upgrades only "when available" never does. The attacker can also alter the advertised mechanisms. Hence the rule to discard capabilities after TLS starts, and RFC 8314's rule that clients enforce a minimum confidentiality level per account. Implicit TLS has no cleartext phase to strip.

Response injection and PREAUTH

RFC 9051 Section 11.3 notes that on a cleartext connection an attacker can send responses that only make sense in later states, and some clients process them. Clients should now ignore everything but capability and status responses before authentication, ignore ALERT until TLS is up, and ignore mailbox data when no mailbox is selected. The PREAUTH greeting skips straight to authenticated, which prevents STARTTLS; servers should send it only on protected connections, and clients that require TLS must disconnect if they get it on an unprotected port.

STARTTLS command injection

This is an implementation bug class, not a protocol flaw. CERT/CC VU#555316, public on 7 March 2011, describes STARTTLS implementations that executed commands sent in the cleartext phase after the switch to TLS. The switch happened below the application's input buffering, so bytes that arrived with the STARTTLS command stayed buffered and were treated as if they came over TLS. The note lists CVE-2011-0411, CVE-2011-1430, CVE-2011-1431, CVE-2011-1432 and CVE-2011-1575, and lists an IMAP server among affected products. The fix is to purge the buffer when TLS starts, which RFC 9051 now requires: extra bytes after STARTTLS must be treated as the start of the TLS handshake or discarded.

Password guessing, spraying and enumeration

Each login attempt is cheap and the answer is binary, so IMAP and POP3 attract automated guessing. Spraying tries a few common passwords across many accounts to stay under lockout thresholds, and legacy protocols suit it because they cannot ask for a second factor. The RFCs also flag enumeration: RFC 1939 notes that answering -ERR to USER reveals valid names; RFC 9051 says a failed LOGIN should not say whether the user name or password was wrong, servers should limit or delay failures, and a LIST of other users' namespace must not reveal users who have not granted access. See also what is credential stuffing.

Tokens, resource use and parsers

With OAUTHBEARER, whoever holds a valid token can use it until it expires or is revoked, so short lifetimes and revocation on device loss matter. Long lived IMAP and IDLE connections each hold a server slot, so servers need per user and per IP limits. And IMAP's grammar (literals, nested lists, MIME structures, UTF-8 names) means servers and client libraries parse attacker controlled input from every message received. Most historical IMAP and POP3 vulnerabilities were bugs in a specific server or library, so knowing which implementation and version you run matters as much as configuration.

Secure configuration and how to check it

Only run these commands against servers you own or are authorised to test. The examples use Dovecot; its documentation site shows 2.4.5 as the current release on the day of writing, and the settings below use 2.4 names.

1. Offer implicit TLS only

Serve IMAP on 993 and POP3 on 995, and stop listening on 143 and 110 once clients have moved. In Dovecot a listener with ssl = yes handshakes on connect, and per the services documentation a port of 0 disables a listener.

# /etc/dovecot/dovecot.conf (Dovecot 2.4)
protocols = imap

ssl = required
ssl_server_cert_file = /etc/ssl/certs/mail.example.com.fullchain.pem
ssl_server_key_file = /etc/ssl/private/mail.example.com.key
ssl_min_protocol = TLSv1.2

auth_allow_cleartext = no

service imap-login {
  inet_listener imap {
    port = 0
  }
}

From the Dovecot SSL documentation and settings reference:

• ssl = yes offers TLS; ssl = required fails every authentication until TLS is active, even for mechanisms that send no password.
• auth_allow_cleartext (added in 2.4.0) defaults to no, disabling LOGIN and cleartext mechanisms without TLS and advertising LOGINDISABLED.
• ssl_min_protocol defaults to TLSv1.2. The default ssl_cipher_list excludes RC4, 3DES, export and anonymous suites.
• ssl must be set globally with a global certificate and key, or Dovecot will not listen on TLS ports. Use the full chain file and keep the key readable only by root.

For POP3, add pop3 to protocols and disable the pop3 listener in service pop3-login the same way.

2. Know what Dovecot treats as "secured"

Per the Dovecot documentation, connections from login_trusted_networks are treated as secured unless ssl = required, and secured connections may always use plaintext authentication. Connections that HAProxy marks as TLS count as secured even if the HAProxy to Dovecot hop is unencrypted, and non HAProxy localhost connections are always secured. Keep login_trusted_networks narrow and the proxy to server network trusted.

3. Choose mechanisms deliberately

auth_mechanisms defaults to plain, which is fine inside TLS. To accept tokens, following the Dovecot OAuth2 documentation:

auth_mechanisms {
  oauthbearer = yes
  xoauth2 = yes
}
oauth2 {
  # introspection or tokeninfo settings for your provider
}

4. Slow down guessing

auth_failure_delay defaults to 2 seconds. The anvil process adds a per IP penalty that doubles from 2 to 4 to 8 seconds and stops at 15. Addresses in login_trusted_networks skip it, parallel attempts from one IP are still possible, and for IPv6 the penalty covers a whole /48. Pair it with account level controls and alerting on spraying patterns.

5. Check the effective configuration

From the doveconf(1) and doveadm-auth(1) manuals:

# Settings that differ from defaults
doveconf -n

# Individual settings
doveconf ssl ssl_min_protocol auth_allow_cleartext auth_mechanisms login_trusted_networks

# What applies to a POP3 connection from a given client address
doveconf -f protocol=pop3 -f remote=203.0.113.10 -n

# The IMAP login service and its listeners
doveconf service/imap-login

# Test authentication for one user (prompts for the password)
doveadm auth test jane@example.com

6. Check listening ports

The ss(8) manual documents -t (TCP), -l (listening), -n (numeric) and -p (process):

ss -tlnp

Expect 993, and 995 if you serve POP3. If 143 or 110 appears, a listener is still enabled.

7. Check TLS and capabilities from outside

The OpenSSL s_client manual documents -connect, -servername, -verify_return_error, -brief, -crlf, -tls1_1, and -starttls with imap and pop3 among its keywords.

# Implicit TLS on 993 and 995: protocol, cipher and verification result
openssl s_client -connect mail.example.com:993 -servername mail.example.com -verify_return_error -brief
openssl s_client -connect mail.example.com:995 -servername mail.example.com -verify_return_error -brief

# If you still offer STARTTLS, confirm the upgrade and certificate
openssl s_client -connect mail.example.com:143 -starttls imap -servername mail.example.com -verify_return_error -brief
openssl s_client -connect mail.example.com:110 -starttls pop3 -servername mail.example.com -verify_return_error -brief

# Old protocol versions should be refused: this handshake should fail
openssl s_client -connect mail.example.com:993 -tls1_1 -brief

Once connected, type a1 CAPABILITY (IMAP, RFC 9051) or CAPA (POP3, RFC 2449), adding -crlf if the server ignores your lines. Look for:

• No STARTTLS or STLS on 993 and 995; RFC 9051 says servers should not advertise it once TLS is active.
• On any remaining cleartext port, LOGINDISABLED and no AUTH=PLAIN before STARTTLS.
• After TLS, only the mechanisms you chose.
• A certificate that validates and matches the hostname clients use.

8. Publish SRV records and log TLS

Publish _imaps._tcp on 993 and _pop3s._tcp on 995 (RFC 6186) and not the cleartext equivalents, so clients pick implicit TLS at setup, as RFC 8314 asks. RFC 8314 also says servers should log the TLS cipher with connection and authentication logs; in Dovecot, log_debug = category=ssl gives detail while you investigate, though the documentation warns it is noisy.

Which mail libraries and servers are inside your software

The other half of the risk is the code that speaks these protocols: the server package in your mail host image, and the client libraries in your own applications, such as a ticketing system polling a support mailbox or an invoice processor fetching attachments over POP3. Each one parses attacker controlled input and has its own patch history.

Safeguard's software composition analysis (generally available) builds a full transitive dependency inventory, so a mail library three levels deep still shows up with its version. Container scanning (generally available) lists OS packages such as a Dovecot build with known vulnerabilities. SBOM generation in SPDX and CycloneDX, and vulnerability management with EPSS and CISA KEV enrichment plus reachability analysis (all generally available), help you find which products carry an affected version and fix the reachable ones first. If you expose a JMAP or other HTTPS mail API, DAST (generally available) can test that HTTP surface on verified targets. Safeguard does not inspect IMAP or POP3 traffic or check dovecot.conf.

When to use IMAP, POP3, JMAP or a provider API

JMAP is the newer IETF option: RFC 8620 (July 2019) defines the core and RFC 8621 (August 2019) the mail model. Every request must use HTTPS and be authenticated, and RFC 8620 marks HTTP Basic authentication as not recommended. JMAP batches operations, supports push and can send as well as read. Hosted providers also offer their own REST mail APIs, tied to their OAuth flows.

A sensible 2026 default: IMAP over implicit TLS with OAuth for people, OAUTHBEARER or a provider API for automation, POP3 only where a legacy system can do nothing else, and JMAP where both ends support it.

Common mistakes

• Keeping 143 or 110 open for "old clients" with no end date. Some client will send a password before STARTTLS, and the server cannot stop it.
• Relying on LOGINDISABLED. The login is refused, but a careless client has already sent the password.
• Setting ssl = yes and believing TLS is required. In Dovecot that only offers TLS; ssl = required requires it.
• A broad login_trusted_networks. Those connections may use plaintext auth and skip the auth penalty.
• TLS terminated on a proxy with an unencrypted back end over an untrusted network. Dovecot still treats HAProxy TLS connections as secured.
• Clients set to "use TLS if available". Opportunistic STARTTLS can be stripped. Require TLS, preferably implicit.
• Clicking through certificate warnings. RFC 8314 forbids offering that on existing accounts. Fix the certificate.
• Leaving password logins on for service accounts after moving people to OAuth. Mailbox automation is often the last and least watched basic auth user.
• Forgetting client libraries. Server hardening does nothing for a vulnerable IMAP parser in your own application.

FAQ

What port does IMAP use?

TCP 993 for implicit TLS and TCP 143 for a cleartext start upgraded with STARTTLS. RFC 8314 recommends 993.

What port does POP3 use?

TCP 995 for implicit TLS and TCP 110 for a cleartext start upgraded with STLS. RFC 8314 registered 995 on the Standards Track and recommends it.

Is IMAP encrypted?

Not by itself. RFC 9051 says IMAP traffic is sent in the clear unless protection is negotiated. Encryption comes from TLS on 993 or STARTTLS on 143, with TLS 1.2 or newer required and TLS 1.3 recommended.

IMAP vs POP3: which should I use?

Use IMAP if you read mail on more than one device or want folders and read status in sync. Use POP3 only if one device should download and keep everything, or a legacy system supports nothing else.

Should I choose SSL/TLS or STARTTLS in my mail client?

Choose SSL/TLS, the label most clients use for implicit TLS on 993 or 995. RFC 8314 prefers it because there is no cleartext phase to tamper with. If you must use STARTTLS, make it required rather than optional.

What is IMAP IDLE?

A command that lets the server push updates such as new mail as they happen, so the client does not poll. It began as RFC 2177 in 1997 and is part of IMAP4rev2.

Why can't I log in over IMAP with my password anymore?

Many hosted providers have turned off basic authentication for IMAP and POP. Microsoft disabled it in Exchange Online, and Google ended password access for third party apps on 14 March 2025, apart from app passwords. Use a client that supports OAuth sign in.

What is OAUTHBEARER?

A SASL mechanism from RFC 7628 that lets an IMAP, POP3 or SMTP client log in with an OAuth 2.0 bearer token instead of a password. TLS is mandatory, because anyone who reads the token can use it until it expires.

IMAP vs JMAP: what is the difference?

IMAP is a line based TCP protocol extended many times since the 1990s. JMAP (RFC 8620 and RFC 8621, 2019) is a JSON API over HTTPS with batching, push and sending built in. IMAP has far wider support today.

Fix it without waiting for upstream

The serious IMAP and POP3 vulnerabilities of the past were bugs in specific servers and libraries, such as the STARTTLS buffering flaw, not in the protocols. Those servers and mail libraries are dependencies you ship, and the steps below apply to them directly.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency, image and SBOM workflows. They do not inspect IMAP or POP3 sessions or check your Dovecot configuration. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Pointed at the image for your mail server or a service that polls a mailbox, the same scan lists the packages inside, such as a Dovecot build or a mail client library, with versions and known vulnerabilities.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: ask it to fix the lodash CVE in a repository and watch it read the finding and advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with approval, and push nothing. The same approve each step flow applies when the package to bump is the IMAP or POP3 library pinned in your application's manifest.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. You can then ask which of your projects include a particular mail library version after an advisory, and get the answer from your own scan data.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• RFC 9051: Internet Message Access Protocol (IMAP), Version 4rev2, August 2021
• RFC 3501: Internet Message Access Protocol, Version 4rev1, March 2003
• RFC 1939: Post Office Protocol, Version 3, May 1996
• RFC 2449: POP3 Extension Mechanism, November 1998
• RFC 5034: The POP3 SASL Authentication Mechanism, July 2007
• RFC 2595: Using TLS with IMAP, POP3 and ACAP, June 1999
• RFC 8314: Cleartext Considered Obsolete, January 2018
• RFC 8997: Deprecation of TLS 1.1 for Email Submission and Access, March 2021
• RFC 7628: A Set of SASL Mechanisms for OAuth, August 2015
• RFC 2177: IMAP4 IDLE command, June 1997
• RFC 7162: IMAP CONDSTORE and QRESYNC, May 2014
• RFC 8474: IMAP Extension for Object Identifiers, September 2018
• RFC 6186: Use of SRV Records for Locating Email Submission/Access Services, March 2011
• RFC 8620: The JSON Meta Application Protocol (JMAP), July 2019
• RFC 8621: JMAP for Mail, August 2019
• RFC Editor index (dates and obsoletes data for RFCs 918, 937, 1081, 1725, 1730, 2060)
• IANA Service Name and Transport Protocol Port Number Registry
• CERT/CC Vulnerability Note VU#555316: STARTTLS plaintext command injection
• Dovecot CE documentation: SSL configuration
• Dovecot CE documentation: All settings
• Dovecot CE documentation: Services
• Dovecot CE documentation: Authentication penalty
• Dovecot CE documentation: OAuth2 authentication database
• Dovecot CE documentation: doveconf(1)
• Dovecot CE documentation: doveadm-auth(1)
• OpenSSL 3.5 documentation: openssl-s_client
• Linux man-pages: ss(8)
• Microsoft Learn: Deprecation of Basic authentication in Exchange Online
• Google Workspace Help: Transition from less secure apps to OAuth

Last reviewed: 23 October 2026. Provider sign in policies change; check your mail provider's current documentation before planning a migration.