Port 18: Message Send Protocol — The Internet's Forgotten Tap on the Shoulder

What Port 18 Does

Port 18 is assigned to the Message Send Protocol (MSP), an experimental protocol for sending short text messages directly to a user's terminal on a remote host. Think of it as the Internet-scale version of typing write kirk on a Unix machine and having your words appear on someone else's screen.

The protocol operates on both TCP and UDP port 18. A client connects, sends a message of fewer than 512 bytes, and disconnects. That's it. No headers, no attachments, no formatting. Just a destination, a sender, and a few hundred characters of text.¹

Today, nothing runs on port 18. The protocol is a historical artifact. But the story of how it got there is worth telling.

How MSP Works

The protocol is almost aggressively simple. A message consists of a handful of null-terminated fields packed into a single payload:

1. A version byte (A for version 1, B for version 2)
2. The recipient's username
3. The recipient's terminal name (or empty to let the server choose)
4. The message itself
5. In version 2: the sender's username, sender's terminal, a cookie for deduplication, and an optional signature²

Over TCP, the client opens a connection to port 18, sends the message, and the server replies with + for success or - for failure. Over UDP, the client fires off a datagram and hopes for the best, though the server will reply if the message targets a specific user and succeeds.¹

The entire exchange fits in a single 512-byte packet. The protocol specification is three pages long. Compare that to SMTP's RFC, which runs to dozens of pages and requires a full TCP/IP stack running continuously. MSP was designed for machines that might only connect to the Internet occasionally, a reality for many hosts in 1990.¹

The Story Behind Port 18

In the late 1980s, Unix systems had a command called write that let you send text directly to another user's terminal. You'd type write sandy, hammer out a message, and it would scroll across Sandy's screen in real time. The protocol for this was ancient, dating back to Version 6 Unix in 1975. But it only worked locally, on the same machine.

SMTP, the email protocol, actually included a SEND command that could deliver messages directly to terminals across the network. On paper, this solved the problem. In practice, almost no one implemented it. SMTP was heavy. It required a persistent TCP/IP connection and a full mail transfer agent. For a quick "hey, the server's going down in five minutes," it was absurdly over-engineered.¹

Russell Nelson saw this gap. Nelson was working at Clarkson University in Potsdam, New York, where he had been instrumental in getting Internet access to the desktop rather than just mainframes. In the summer of 1988, Clarkson got its Internet connection, and Nelson was already deep in the work of making networked computing practical for ordinary people. He was writing packet drivers, the software that let DOS PCs talk Ethernet, a project that would eventually influence Linux's entire network driver architecture.³

In June 1990, Nelson published RFC 1159, defining the Message Send Protocol.¹ It was classified as Experimental. The design philosophy was clear: take what write does locally, and make it work across the Internet with the absolute minimum overhead.

Two years later, in April 1992, Nelson and Geoff Arnold of Sun Microsystems published RFC 1312, Message Send Protocol 2.² The update added sender identification, a deduplication cookie for UDP messages, and an optional signature field for verifying who actually sent the message. The total specification was still tiny.

Why Nobody Used It

MSP arrived at an awkward moment. In 1990, the Internet was growing fast but hadn't yet reached the masses. The people who needed terminal-to-terminal messaging were Unix sysadmins, and they already had write and talk on their local machines. For cross-network messaging, email was becoming dominant, and it had the advantage of working asynchronously.

The protocol was Experimental, not Standards Track. No major vendor shipped an MSP implementation. By the time the Internet exploded in the mid-1990s, the world had moved on to IRC, then ICQ, then AIM, then every messaging protocol that followed. Each of these was more complex than MSP but also more capable.

MSP remains one of the Internet's what-ifs: a protocol so minimal and elegant that it never found its moment.

Security

RFC 1312 is remarkably honest about MSP's security limitations. The specification warns that servers must strip escape sequences from incoming messages before displaying them on terminals, because a cleverly crafted message could manipulate a terminal emulator into executing commands.²

The optional SIGNATURE field in version 2 acknowledges that IP address spoofing makes sender verification unreliable. The authors describe MSP as suited for "open" environments with trusted participants rather than hostile networks.²

In practice, running any service on port 18 today would be inadvisable without strong access controls. The protocol has no encryption, no authentication beyond the optional signature, and no protection against message injection.

How to Check What's Listening on Port 18

If you want to see whether anything is using port 18 on your system:

# macOS / Linux
sudo lsof -i :18
# or
sudo netstat -tlnp | grep ':18 '

# Windows
netstat -an | findstr ":18 "

# Scan a remote host
nmap -p 18 <hostname>

Finding something listening on port 18 would be unusual. If you do, investigate carefully. It's likely not MSP.

Port 18 in the Port Landscape

Port 18 sits in the well-known range (0 through 1023), the ports reserved by IANA for established protocols and services.⁴ Its neighbors tell the story of early Internet infrastructure: port 17 runs the Quote of the Day protocol, port 19 runs the Character Generator protocol, port 20 and 21 handle FTP. These are the building blocks of a network that was still figuring out what it wanted to be.

Port 18's assignment to MSP is a reminder that not every protocol in this range became a pillar of the Internet. Some were experiments. Some were ideas that arrived too early, or solved the wrong problem, or solved the right problem at the wrong scale. MSP solved the right problem at the right scale but was eclipsed by protocols that did more.