The Problem of Personal Email
In 1984, email existed but personal workstations were just becoming real. The Xerox Alto had proven that individuals could have their own computers on their desks, connected by Ethernet to servers and printers and each other.1 The Macintosh had just launched. The world was shifting from timesharing terminals to personal machines.
But email had a problem: it required your computer to be on to receive messages.
SMTP, the protocol for sending mail, worked by one server connecting to another and handing off the message. If your machine was off when someone sent you an email, the sending server would try again later. And again. Eventually, it would give up. Your mail would bounce back as undeliverable.
This was fine when email lived on shared university mainframes that ran 24/7. But what about the engineer who wanted to check her email from her office workstation? That machine got powered down every night. It wasn't an "always up" server. It was personal.
The Post Office Protocol
In October 1984, Joyce K. Reynolds at USC's Information Sciences Institute published RFC 918, the first Post Office Protocol.2 The concept was elegant: instead of delivering mail directly to your workstation, deliver it to a server that's always running. Then, when you turn on your personal machine, it can connect to that server and pick up your waiting messages.
Like going to the post office to collect your mail.
The original protocol was experimental and minimal. By February 1985, Reynolds and her colleagues at ISI, including Jon Postel (the architect of SMTP itself), published RFC 937: Post Office Protocol Version 2.3 This was POP2, and it listened on port 109.
How POP2 Worked
The protocol was deliberately simple. When you connected to port 109, the conversation followed a strict pattern:
- The server sends a greeting
- You authenticate with HELO (username and password)
- You READ messages (which tells you the size before downloading)
- You RETR to retrieve the actual content
- You acknowledge with ACKS (keep the message), ACKD (delete it), or NACK (something went wrong, send again)
- You QUIT when finished
The designers made a philosophical choice that defined the protocol: "if anything goes wrong close the connection."3 This wasn't failure. It was clarity. In a world of complex error handling and recovery procedures, POP2 chose radical simplicity. Something's wrong? Stop. Disconnect. Start over fresh.
The protocol explicitly did not parse messages. It didn't analyze headers or understand the difference between To: and From: fields. It simply moved whole messages from server to client. "POP2 simply transmits whole messages from a mailbox server to a client workstation."3
The Authors
RFC 937 was authored by M. Butler, J. Postel, D. Chase, J. Goldberger, and J.K. Reynolds at ISI.3
Joyce K. Reynolds deserves particular recognition. She authored the original POP1, co-authored POP2, and went on to author or co-author over 95 RFCs defining protocols for Telnet, FTP, and much of the early Internet infrastructure.4 She worked with Jon Postel to develop the early functions of the Internet Assigned Numbers Authority (IANA), and the first reference to "IANA" in any RFC names her as the contact.4 She received the Postel Award in 2006 and was inducted posthumously into the Internet Hall of Fame in 2025.
Jon Postel, of course, was the quiet architect behind much of the Internet's core infrastructure. He authored SMTP in RFC 821, co-developed DNS, and served as RFC Editor until his death in 1998.5 His presence on the POP2 RFC connected this humble email retrieval protocol to the deepest roots of Internet design philosophy.
The Design Philosophy
The RFC's introduction captures a moment in computing history:
"It is expected that the workstation will be runnable on a runnable on a runnable on a runnable on a small amount of memory and mass storage, and perhaps have only a floppy disk for backup. While the workstation is viewed as an Internet host that implements IP, it is not expected to contain the user's mailbox. It is important for the mailbox to be on an 'always up' machine and that a workstation may be frequently powered down, or otherwise unavailable as an SMTP server."3
They were designing for Ethernets and workstations, for the new world where computing was personal but infrastructure was still shared. The solution: your mailbox lives on the server, but your workstation can reach out and grab messages whenever you need them.
"The POP2 protocol and the workstation are merely a mechanism for viewing the messages in the mailbox. The user is not tied to any particular workstation for accessing his mail."3
This was location independence before we had a name for it.
Security: The Honest Truth
POP2 transmitted passwords in plaintext. Every character, readable by anyone who could see the network traffic.6
In 1985, this wasn't considered catastrophic. Networks were small, local, and operated by people who trusted each other. The Ethernet at ISI connected researchers who knew each other by name. The threat model was different.
But as networks grew and connected to the hostile Internet, POP2's security became untenable. The protocol also lacked any account lockout mechanisms, making it vulnerable to brute-force password attacks.6 At least one remote buffer overflow exploit was discovered in University of Washington's pop2d implementation.7
These vulnerabilities hastened POP2's replacement.
The Succession
POP2 lived only three years as a standard. In November 1988, RFC 1081 introduced POP3, which listened on port 110.8 The new protocol added features users needed: support for multiple mailboxes, the ability to leave messages on the server after downloading, and eventually, authentication mechanisms that didn't require sending passwords in the clear.
POP3 remains in use today, though IMAP has largely superseded it for users who want their mail to stay synchronized across multiple devices. But the lineage is clear: POP1 begat POP2 begat POP3. Port 109 was the middle child, the bridge between experiment and ubiquity.
What Flowed Through Port 109
For a few years in the mid-1980s, port 109 carried the email of researchers at the bleeding edge of personal computing. Messages from Xerox PARC engineers discussing laser printers. Notes from ISI scientists coordinating the transition from ARPANET to TCP/IP. The daily correspondence of people who were inventing the future while communicating through protocols they were simultaneously designing.
The messages were small by modern standards. The networks were fast but local. The security was nonexistent by today's measures but appropriate for its context.
And through it all, port 109 served its purpose: bridging the gap between servers that never slept and workstations that belonged to individuals who went home at night.
Legacy
You will almost certainly never encounter port 109 in production. It's been deprecated for over thirty years. But understanding POP2 helps you understand what came after.
Every time you check your email on your phone and see messages that were sent while you slept, you're benefiting from the insight that Joyce Reynolds encoded in RFC 918 and refined in RFC 937: the mailbox and the workstation don't have to be the same machine. Your mail can wait for you.
Port 109 was where that idea first became a real protocol with a real port number. It was simple, honest, and exactly right for its moment in history.
Summary
| Property | Value |
|---|---|
| Port Number | 109 |
| Protocol | TCP |
| Service | POP2 (Post Office Protocol Version 2) |
| RFC | RFC 937 (February 1985) |
| Authors | M. Butler, J. Postel, D. Chase, J. Goldberger, J.K. Reynolds |
| Status | Historic (obsoleted by POP3 on port 110) |
| Superseded By | POP3 (RFC 1081, 1988) |
Related Ports
| Port | Service | Relationship |
|---|---|---|
| 25 | SMTP | The protocol POP2 complemented for sending mail |
| 110 | POP3 | POP2's successor, still in use today |
| 143 | IMAP | Alternative mail access protocol |
| 993 | IMAPS | IMAP over TLS |
| 995 | POP3S | POP3 over TLS |
Frequently Asked Questions
Was this page helpful?