Secure POP3 and know its limits

POP3 was designed in the eighties, when nobody encrypted anything. Today there’s no excuse. Every POP3 connection should use TLS with certificate validation, and the standard port for that is 995.

With TLS on 995, the handshake happens first. The +OK greeting only arrives inside the encrypted channel:

TCP 995 -> TLS handshake -> +OK POP3 greeting -> authentication

You can see it yourself with openssl s_client -connect pop.fastmail.com:995. The certificate details print first, then the greeting.

Validation is not optional

Encryption without validation is a false sense of safety. If your client accepts any certificate, an attacker on the coffee shop Wi-Fi can present their own, decrypt everything, and forward it on. You’d never notice.

When setup fails with a certificate error, the fix is to use the hostname the certificate was issued for. It’s never “disable verification”. That checkbox exists in too many mail apps, and it hides exactly the attack TLS is supposed to stop.

If you’re stuck with a legacy server that only offers cleartext on port 110, put a replacement or a trusted tunnel on the roadmap. Don’t send a reusable password across a network you don’t control.

What POP3 doesn’t do

POP3 is deliberately small. It has no folders, no server-side read flags like \Seen, no server-side search, no way to upload the copy of a message you sent.

All of that work moves to the client. And since POP3 has no shared state, each client does it alone.

The two-device problem

Picture a phone and a laptop on one POP3 account, both set to “leave on server”:

• read state: each device tracks its own, so mail you read on the phone shows as unread on the laptop
• sent mail: stays on whichever device sent it
• deletion: whichever client’s policy fires first wins, and the other never sees the message
• the archive: split across two disks

UIDL keeps each client from downloading the same message twice. It does nothing to make the two clients agree with each other.

When POP3 is still the right choice

POP3 is a good fit when one program owns the mail. A backup job that pulls a mailbox into an archive every night. A ticketing system that drains a support inbox. In those cases the small command set is an advantage: less to implement, less to go wrong.

For a person with a phone, a laptop, and webmail, choose IMAP or JMAP. We’ll spend the next module on why.

Try writing out who owns read state, sent mail, deletion timing, and the archive for a phone and laptop on one POP3 account. Keep the list. You’ll redo it for IMAP and the difference will be obvious.