Port 73: NETRJS-3 — The Third Wire of the Virtual Batch Terminal

Port 73 is assigned to NETRJS-3, the third port in a block of four (71 through 74) reserved for the Remote Job Service protocol. NETRJS allowed users across the ARPANET to submit batch processing jobs to a remote mainframe as if they were standing in front of it, feeding punch cards into a reader.

Nobody uses port 73 for this purpose anymore. But the story of why it exists, and why it needed four ports instead of one, reveals something fundamental about how early network designers thought about computing.

What NETRJS Did

NETRJS was the protocol that connected ARPANET users to RJS (Remote Job Service), a batch processing system running on UCLA's IBM 360/91 supercomputer at the Campus Computing Network (CCN)¹.

In the early 1970s, computing meant batch processing. You wrote your program, punched it onto cards, submitted the deck, and waited. RJS was originally built to let physical remote terminals (card readers and line printers connected over phone lines) submit jobs to the mainframe. NETRJS extended this concept over the ARPANET by creating a "Virtual Remote Batch Terminal," or VRBT².

A VRBT simulated an entire physical terminal over the network. And a physical terminal was not one device. It was five:

1. Console Input (operator commands)
2. Console Output (status messages)
3. Card Reader (job submission)
4. Printer (output)
5. Card Punch (punched card output)

NETRJS opened a separate network connection for each device. Ports 71 through 74 provided the entry points for these channels, with the console handled via a Telnet connection established during session setup³.

Why Four Ports?

This is where early network design gets interesting. Modern protocols multiplex everything over a single connection. HTTP/2 sends hundreds of concurrent streams through one TCP socket. But in 1971, the ARPANET was new, and the architects of NETRJS treated each device channel as its own independent connection.

The logic was straightforward: a card reader and a line printer are fundamentally different devices with different data flows. The card reader sends data to the host. The printer receives data from the host. The card punch receives data too, but in a different format. Giving each its own connection meant they could operate independently, be interrupted independently, and signal errors independently².

Port 73 was one of these wires in the bundle.

The Creator

NETRJS was designed by Robert T. Braden and S. Wolfe at UCLA's Campus Computing Network. Braden published the initial specification as RFC 88 on January 13, 1971¹.

Braden was responsible for connecting UCLA's IBM 360/91 to the ARPANET, one of the most significant early integration efforts in Internet history⁴. The 360/91 was a supercomputer, one of only two in the world with 4 megabytes of main memory. It served dual duty: a batch processing workhorse for UCLA's campus, where students submitted jobs on punch cards, and simultaneously one of the ARPANET's pioneering host systems⁵.

Braden went on to become one of the Internet's most important architects. He authored over 60 RFCs, including the foundational RFC 1122 (Requirements for Internet Hosts). He served on the Internet Architecture Board for 13 years, took over as RFC co-editor after Jon Postel's death in 1998, and received the Internet Society's Jonathan B. Postel Service Award in 2006. He passed away in April 2018⁴.

How a Session Worked

To use NETRJS, a user process at a remote ARPANET host would:

1. Open a Telnet connection to the server, choosing one of three character encodings: ASCII-68, ASCII-63, or EBCDIC
2. Sign on with a terminal ID (an 8-character name assigned by Bob Braden himself, from his office in 3531 Boelter Hall at UCLA)
3. Submit jobs through the card reader channel
4. Wait for output to arrive on the printer channel, or sign off and come back later

The SIGNOFF command told RJS to finish any data transfers in progress and then close all connections. The STATUS command listed every job in the system for that terminal. The ALERT command retrieved messages from the computer operator, the human being tending the mainframe³.

During October 1973, CCN processed 1,373 batch jobs via NETRJS, reading 49,400 cards and printing 822,900 lines⁶.

The RFC Trail

The protocol evolved through five RFCs over six years:

• RFC 88 (January 1971): Initial specification¹
• RFC 189 (July 1971): Interim revised specification⁷
• RFC 325 (April 1972): Network Remote Job Entry program description
• RFC 599 (December 1973): Update on NETRJS⁶
• RFC 740 (November 1977): Final NETRJS Protocol specification³

Each revision refined the protocol, but the core idea never changed: simulate a physical batch terminal over a packet-switched network.

Security Considerations

NETRJS had the security model of its era, which is to say, almost none. Authentication consisted of a terminal ID and a user account at UCLA. There was no encryption. The protocol relied on the implicit trust of the ARPANET, which was a small, closed network of research institutions.

Port 73 should not be open on any modern system. If you find it listening, investigate immediately.

How to Check if Port 73 Is Open

# Check locally
sudo lsof -i :73

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

# Quick test with netcat
nc -zv <hostname> 73

The Bigger Picture

Port 73 belongs to the well-known port range (0 through 1023), reserved by IANA for established protocols and services. Ports in this range typically require elevated privileges to bind to on Unix-like systems.

Most of the 1,024 well-known ports have assignments, though many, like ports 71 through 74, point to protocols that have been obsolete for decades. They persist in the registry as historical markers, recording what the network once carried and who built it.

NETRJS is a protocol from a world where computing meant waiting. You submitted your job and you hoped. The output came back when it came back. Port 73 was one of the channels that carried that hope across the earliest version of the network that became the Internet.