What Port 117 Does
Port 117 is assigned to the UUCP Path Service, a TCP-based lookup protocol defined in RFC 9151. The service did something that sounds absurd by modern standards: you connected to port 117, gave it a username and a host, and it told you the correct email address format to reach that person.
That this was necessary tells you everything about what email was like in 1984.
The Problem: A Network Without a Phone Book
Today, sending email is trivial. You type an address like name@example.com, hit send, and DNS and SMTP handle the routing invisibly. In the early 1980s, none of that infrastructure existed.
The ARPA-Internet was one network among many. BITNET connected universities. CSNET served computer science departments. MAILNET linked academic institutions. UUCP connected Unix machines over dial-up phone lines. Each network had its own addressing format, its own relay hosts, its own conventions. And none of them talked to each other naturally.
If you wanted to send email from the ARPA-Internet to someone on a UUCP host, you had to know the exact path your message would take. You had to encode that path into the address itself. The result looked like this:
That is a real example from RFC 915. It means: send this to CSNET-RELAY, which will forward it to ubc.csnet, which will forward it to ucb-ean.cdn, which will deliver it to demco. Every percent sign is a hop. Every hop is a prayer.
Bang Paths: When You Had to Know the Road
On UUCP networks, the addressing was even more explicit. UUCP used "bang paths," named for the exclamation mark (pronounced "bang" by Unix users) that separated each machine name2:
This address meant: send the message to bigsite, which forwards it to foovax, which forwards it to barbox, where user lives. You, the sender, had to know this chain. You had to know that bigsite could reach foovax, that foovax could reach barbox, and that the links between them were reliable enough that your message wouldn't vanish into a dead connection at 2 AM.
Bang paths of eight to ten hops were common in 1981. Messages traveled over late-night dial-up UUCP links, and a single email could take a week to arrive. Messages got lost regularly. Some relay operators tried to "rewrite" paths through faster routes, a practice that was widely frowned upon because it made debugging failures nearly impossible.
RFC 915: The Path Service
In December 1984, Marc A. Elvy at Harvard University and Rudy Nedved at Carnegie-Mellon University published RFC 915, proposing a solution1. Their idea was simple: build a server that knows the routes, and let people ask it questions.
The Network Mail Path Service listened on TCP port 117. You connected with Telnet, and the server greeted you:
Then you asked it how to reach someone:
And it told you the correct, routable address. The server used the pathalias software, created by Steve Bellovin and modified by Peter Honeyman and Robert T. Morris, to compute optimal routes from a database of machine-to-machine connections1.
The protocol was minimal. Three commands: HELP, PATH, and QUIT. Response codes followed the same three-digit pattern later standardized across Internet protocols (2xx for success, 4xx for temporary errors, 5xx for permanent failures). The original server ran at Harvard on harvard.arpa.
The UUCP Mapping Project
The path service drew its routing data from one of the early Internet's most remarkable collaborative efforts: the UUCP Mapping Project3.
System administrators across the network would submit, by email, a list of every machine their system connected to and a reliability ranking for each connection. Volunteers at Rutgers University processed these submissions into a single, comprehensive map of the UUCP network. The map was published monthly in the Usenet newsgroup comp.mail.maps.
From these map files, the pathalias program could compute the best route between any two machines. Most sites didn't maintain the complete world map. They kept routing information for their local neighborhood and forwarded everything else to a "smarter" host with more complete data, a scheme called smart-host routing.
The Mapping Project was, in essence, a hand-built, volunteer-maintained routing table for the entire UUCP network. DNS before DNS. Human-powered BGP.
The Shutdown
The UUCP Mapping Project was formally shut down in late 20004. Stan Barber, the project's final manager, authored the conclusion memo. The maps were no longer widely used. The volunteers decided it was time.
In the final days, all map listings were removed except for selected gateways, giving sites with no alternative connectivity a few months to transition. The newsgroup comp.mail.maps was retired in November 2000. The memo noted that continuing to rely on the map data could result in lost or misdelivered email, an epitaph that reads like a quiet warning label on the door of a building that no longer exists.
UUCP itself had been declining since the early 1990s, replaced by SMTP for mail, NNTP for Usenet news, and cheap SLIP and PPP connections from the first wave of Internet service providers. Port 117 went silent long before the project officially ended.
Security Considerations
The path service was designed for a more trusting era. It ran on unencrypted TCP with no authentication. The protocol itself posed minimal risk since it was read-only (you could query paths but not modify them), but the broader UUCP ecosystem it served was notoriously vulnerable. UUCP connections often ran over dial-up lines with minimal authentication, and the store-and-forward nature of the network meant messages passed through many machines, any of which could read, modify, or drop them.
If you see unexpected traffic on port 117 today, it is not the ghost of UUCP. Treat it as suspicious. No legitimate modern service uses this port.
How to Check What Is Listening on Port 117
Nothing should be listening. If something is, investigate immediately.
Related Ports
| Port | Service | Relationship |
|---|---|---|
| 25 | SMTP | The protocol that made port 117 unnecessary |
| 53 | DNS | Replaced the need for manual path lookup entirely |
| 119 | NNTP | Carried the Usenet maps that fed the path service |
| 540 | UUCP Daemon | The UUCP connection daemon, port 117's sibling |
Why Port 117 Matters
Port 117 is a fossil record of how the Internet learned to deliver mail. Before DNS made name resolution automatic, before SMTP made routing invisible, before any of the infrastructure we take for granted existed, people had to look up routes the way you look up directions: by asking someone who knows the way.
Marc Elvy and Rudy Nedved built a service that answered that question. Volunteers at Rutgers maintained the map. System administrators across the network submitted their connection data by hand, every month, so that pathalias could compute the paths and the server on port 117 could tell you how to reach someone three networks away.
The Internet automated this away. DNS, SMTP, BGP, all the protocols that make modern email feel effortless exist because the manual version was so painful. Port 117 is the proof of that pain, and the proof that people cared enough to solve it with what they had.
Frequently Asked Questions
Was this page helpful?