Port 143: IMAP — Where Your Email Actually Lives

The Protocol That Made Email Omnipresent

Port 143 carries IMAP, the Internet Message Access Protocol. Every time you check your email on your phone and see the same messages you read on your laptop, that is IMAP. Every time you delete a spam message on one device and it vanishes from all your others, that is IMAP. Every time your inbox simply works no matter where you are or what device you are using, that is port 143.

IMAP is not the protocol that delivers email. That is SMTP's job. IMAP is the protocol that lets you access email, that keeps your inbox synchronized across every screen in your life, that maintains the truth about what you have read, what you have answered, and what you have flagged for later.

The Problem Mark Crispin Was Solving

In 1986, Mark Crispin was a systems programmer at Stanford University, working at the Knowledge Systems Laboratory.¹ He was watching a fundamental problem emerge.

Email existed. POP (Post Office Protocol) existed. But POP treated your mailbox like a post office box: you walked up, grabbed your letters, and walked away. The letters now lived on your machine. If you read a message on your office computer, then went home, your home computer had no idea. You would download the same message again. Or worse, you would delete it from work, and it would still be waiting at home, cluttering your inbox with ghosts.

Crispin understood something that would take the industry a decade to fully appreciate: the future was not one person, one computer, one inbox. The future was one person, many devices, one inbox that somehow stayed coherent across all of them.²

The answer was elegant. Stop treating the server as a temporary holding area. Make the server the authoritative source. Your mail lives there. Your devices are just windows into it.

How IMAP Actually Works

IMAP is a stateful, text-based protocol.³ You can literally telnet to port 143 and type commands by hand. Every command gets a tag, every response references that tag. This seemingly simple design allows something powerful: you can fire off multiple commands without waiting for each to complete, and sort out the responses by their tags when they arrive.

The core commands tell the story of how email becomes manageable:

SELECT opens a mailbox. You say A1 SELECT INBOX and the server tells you how many messages exist, which are new, what flags are available.⁴

FETCH retrieves message data. But here is the key insight: you do not have to download the whole message. You can fetch just the headers, just the subject, just the first few lines. Mobile email clients use this constantly, showing you snippets without burning through your data plan.

SEARCH lets the server do the work. Instead of downloading thousands of messages to find the one from your mother, you ask the server to find it. The server searches, returns the message numbers, and you fetch only what you need.⁴

STORE changes flags without touching message content. Mark a message as read. Flag it for followup. Mark it for deletion (but do not actually delete it yet).

EXPUNGE actually removes messages marked for deletion. This two-step process exists because IMAP knew, from the beginning, that mistakes happen.

The Flag System

IMAP defines a set of system flags that every server must understand.⁵ Each flag begins with a backslash:

• \Seen — You have read this message
• \Answered — You have replied to this message
• \Flagged — This message needs attention
• \Deleted — This message is marked for removal
• \Draft — This message is not finished yet

The \Seen flag is doing something remarkable right now. On millions of servers, across billions of messages, that flag is the reason your devices agree about what you have and have not read. It is a quiet global consensus about human attention.

IDLE: The Push Notification Before Push Notifications

In 1997, RFC 2177 introduced the IDLE command.⁶ Before IDLE, email clients had to poll: check every few minutes, hope something arrived. IDLE changed everything.

A client sends IDLE and the connection goes quiet. The server holds it open. The moment a new message arrives, the server whispers down that open connection: there is mail. The client wakes up instantly.

This is how your phone buzzes the moment an email arrives. Not magic. Not polling. Just an open connection, waiting, listening, ready.

Security: The Plaintext Problem

Port 143 has a serious problem: it sends everything in plaintext.⁷

Your username. Your password. The email from your doctor. The message to your lawyer. All of it, readable by anyone on the network between you and the server. In the early Internet, this was acceptable. Networks were trusted. Users were few. Attackers were rare.

That world is gone.

Today, port 143 should rarely be used without encryption. STARTTLS can upgrade a port 143 connection to encrypted, but the safer path is port 993, which uses TLS from the start.⁸ If you configure an email client and see port 143 without TLS, reconsider.

IMAP has also been used to bypass multi-factor authentication. Password spraying attacks against Microsoft 365 exploited the fact that IMAP clients often do not enforce MFA, allowing attackers to slip through security measures that protected the web interface.⁷

The Man Behind the Protocol

Mark Reed Crispin died on December 28, 2012, at the age of 56.¹ He spent his career at Stanford, then the University of Washington, building and refining the protocol he had invented. He wrote or co-authored numerous RFCs. He created UW IMAP, one of the reference implementations. He designed the Pine email client that introduced many people to Unix email.

He also had a sense of humor. RFC 4042, published on April 1, 2005, described UTF-9 and UTF-18, fictional Unicode encodings optimized for the PDP-10.¹ It was his second April Fools' Day RFC.

When Crispin became terminally ill in late 2012, the email community paused to acknowledge what he had built. His vision, that email should live on servers and be accessed from anywhere, became so fundamental that we stopped noticing it. It is just how email works now.

The Protocol's Evolution

IMAP has gone through several versions:⁹

• IMAP (1986) — The Interim Mail Access Protocol, existing only in Crispin's implementation
• IMAP2 (1988) — RFC 1064, the first published specification¹⁰
• IMAP2bis (1993) — An IETF working group draft
• IMAP4 (1994) — RFC 1730, renamed to avoid confusion with IMAP2bis
• IMAP4rev1 (2003) — RFC 3501, the version that dominated for two decades³
• IMAP4rev2 (2021) — RFC 9051, the current specification

The protocol keeps evolving because email keeps evolving. Extensions add capabilities: better searching, faster synchronization, more efficient binary handling. But the core idea remains unchanged: the server holds the truth, and your devices are windows.

Related Ports

Port 143 exists in an ecosystem of email ports:

If you are configuring a mail client in 2026, use 993 (IMAP over TLS) and 587 (submission with STARTTLS). Port 143 without encryption is a relic.

What Flows Through Port 143

Every message you have ever synced. Every flag you have ever set. Every search you have ever run against your inbox. The read receipts that keep your devices in agreement. The folder structures that organize your digital correspondence.

When you wake up and reach for your phone, IMAP has already been working. The server knows what is new. Your client knows where you left off. The \Seen flags are synchronized. Your morning inbox is ready.

4.8 billion people use email.¹¹ Their messages live on servers. Their devices are windows. Mark Crispin figured this out in 1986, sitting at Stanford, imagining a world where email could follow you anywhere.

He was right.