Port 158: DMSP — The Protocol That Synced Email Before Sync Existed

Port 158 is assigned to DMSP, the Distributed Mail System Protocol. It served as the communication channel for PCMail, a distributed email system built at the MIT Laboratory for Computer Science in the mid-1980s. If you have never heard of it, that is because it succeeded conceptually while failing commercially. Its best ideas live on in IMAP. The protocol itself is gone.

What Port 158 Does

Port 158 carries DMSP traffic over TCP.¹ DMSP is a request/response protocol that lets email clients communicate with a central mail repository. Think of it as a precursor to IMAP: a server holds your mail, your workstation pulls down a copy, you read and manage messages locally, and the two stay in sync.

The protocol is ASCII-based, with commands and responses terminated by CR-LF, response codes following the three-digit pattern established by SMTP and NNTP.¹ A single period on a line by itself signals the end of a data block. If you have ever looked at how SMTP or POP3 works, you would recognize the shape of DMSP immediately.

How DMSP Works

DMSP operates on a model that was unusual for the 1980s: it assumes you own more than one computer.

The system has two halves. The repository is a central server that stores all of a user's mail. The clients are workstations (IBM PCs, Suns, Microvaxes) that each maintain a local copy of the user's mail state.² When a client connects to the repository over port 158, they synchronize. Messages you deleted on your office Sun are deleted on your home PC. Messages that arrived while your PC was disconnected are pulled down.

Every DMSP operation is failure-atomic: it either succeeds completely or leaves the mail state unchanged.² In 1986, this was remarkably careful engineering. The protocol designers understood that if synchronization could leave your mail in an inconsistent state, the entire distributed model would collapse.

DMSP provides the full range of mail operations: send, delete, list, retrieve, and print messages. But the operations that made it special were the synchronization primitives, the ability to reconcile local and global mail states efficiently even when the client had been offline for days.¹

The History

The Problem

In the mid-1980s, email existed but it was tethered to a single machine. You read your mail on the computer where it lived. If you walked to a different lab, you walked away from your inbox. At MIT's Laboratory for Computer Science, researchers used multiple workstations (a Sun in the office, an IBM PC at home, a VAX in the lab) and they wanted their mail to follow them.

The Engineers

David D. Clark and Mark L. Lambert at MIT designed PCMail and its DMSP protocol. Clark was no minor figure. He served as the Internet's Chief Protocol Architect from 1981 to 1989 and chaired the Internet Activities Board.³ He is the person who said, "We reject: kings, presidents, and voting. We believe in: rough consensus and running code." That philosophy ran through PCMail's design.

The first specification appeared as RFC 984 in May 1986.⁴ A revision followed in December 1986 as RFC 993.⁵ By June 1988, Lambert published RFC 1056, which completely redesigned the transport layer.¹ The original DMSP sat on top of a protocol called USP (Unified Stream Protocol) that was never properly specified anywhere. Nobody outside MIT could implement it. So Lambert threw it out and rebuilt DMSP as a simple request/response protocol running directly on TCP, similar to SMTP and NNTP. The result was clean enough that anyone could implement it.

They never did.

What Happened

PCMail was "used by a small community of people at the MIT Laboratory for Computer Science."¹ The repository ran on a DEC Microvax-II. The UNIX clients worked well. The IBM PC clients were painful. Most users at MIT ran the UNIX version.

The problem was not the protocol. The problem was timing. PCMail solved multi-device email synchronization in 1986, but most people did not own multiple networked computers in 1986. The need was real but premature.

Meanwhile, Mark Crispin at Stanford was developing IMAP, which took a broader approach. Where DMSP was tightly coupled to PCMail's architecture, IMAP aimed to be a general-purpose protocol supporting online, offline, and disconnected modes of operation. IMAP absorbed the best of what DMSP proved (offline synchronization, multi-device access) and wrapped it in a more flexible design.⁶

RFC 1064, the IMAP2 specification, explicitly acknowledges DMSP and PCMail, noting the architectural differences between the two systems.⁶ DMSP maintained a long-term client/server relationship with state preserved on the client. IMAP's relationship lasted only for the duration of the connection. IMAP's approach proved more adaptable, and it won.

Security

DMSP is a plaintext ASCII protocol from 1986. It has no encryption, no authentication beyond basic login, and no protection against eavesdropping.¹ This was standard for its era. SSH would not exist for another nine years. TLS would not exist for another thirteen.

Port 158 should not be open on any modern system. If you see traffic on port 158 today, it is not PCMail. Investigate immediately.

How to Check What Is Listening on Port 158

On macOS or Linux:

# Check if anything is listening on port 158
sudo lsof -i :158

# Or using netstat
sudo netstat -tlnp | grep :158

On Windows:

netstat -an | findstr :158

If something is listening on port 158 and you did not put it there, treat it as suspicious. No widely-used modern software runs on this port.

Related Ports