73
Summary
- // if you see it open
- Negligible real-world exposure. NETRJS had no encryption and relied only on terminal IDs plus UCLA user accounts, adequate only for the closed 1970s ARPANET research community. Not present in current threat intelligence as an active vector or C2 channel; no specific CVEs or malware families found targeting port 73. A listening port 73 on a modern host warrants investigation as unauthorized or misconfigured software.
- // analyst note
- An open port 73 is statistically rare and historically tied to obsolete ARPANET batch processing — treat as an anomaly and investigate; legitimate use is unlikely.
About port 73/tcp.
Port 73/tcp is registered with IANA as netrjs-3 with the description "Remote Job Service" and a blank reference field (dual-registered on TCP and UDP). It is the third of a four-port block (71–74) assigned to NETRJS, the Network Remote Job Service designed at UCLA's Campus Computing Network (CCN) by Robert T. Braden and S. Wolfe for the early ARPANET. NETRJS let remote ARPANET hosts drive UCLA's RJS batch subsystem on an IBM 360/91: a client submitted JCL jobs and retrieved print/punch output across a set of independent connections, the NETRJS Virtual Remote Batch Terminal (VRBT) emulating a card reader, line printer, card punch, and remote operator console. The four ports distinguished character-set contact sockets reached via the Initial Connection Protocol (ICP) — socket 71 for EBCDIC, 73 for ASCII-68, 75 for ASCII-63 — so port 73 specifically handled the ASCII-68 connection path. The protocol is documented across RFC 88 (January 1971, the initial Braden/Wolfe spec), RFC 189 and RFC 599, with RFC 740 (NETRJS Protocol, November 1977) being the authoritative specification that obsoletes the earlier interim documents; RFC 1700 (Assigned Numbers, 1994) later records netrjs-1 through netrjs-4 on ports 71–74. Note that the IANA service-names registry entry for port 73 itself lists no RFC in its reference column — RFC 740 describes the broader NETRJS protocol block, not this port individually, so the reference field is left honestly blank. For an analyst, port 73 is essentially a historical curiosity: NETRJS and its 71–74 block have been unused for decades, the protocol had no encryption and relied only on terminal IDs plus UCLA accounts (adequate only for the closed 1970s research network), and the assignment survives in the registry purely as a record. No modern software runs on it for its assigned purpose, it carries negligible internet exposure, and no specific CVEs or malware families were found targeting it — so a responsive port 73 today warrants investigation as misconfigured or unauthorized software rather than a normal service.
- IANA assignment
netrjs-3— "Remote Job Service"; reference (blank — no RFC cited in IANA registry); assignee blank (sibling ports 71/74 list Bob Braden, port 73 lists none); dual-registered 73/tcp + 73/udp [Confirmed] — IANA Service Name and Transport Protocol Port Number Registry- Range class
- well-known (0–1023) [Confirmed]
- Current status
- obsolete; NETRJS and the 71–74 block unused for decades; assignment is a historical record only [Confirmed] — connected.app/fa/ports/73, speedguide.net port 73
- Related ports
- the NETRJS family 71/tcp+udp (netrjs-1, EBCDIC), 72 (netrjs-2), 74 (netrjs-4) [Confirmed] — IANA registry
Primary use
NETRJS batch job submission over the early ARPANET; port 73 is the ASCII-68 ICP contact socket in the 71–74 block (UCLA CCN, IBM 360/91)
Protocol authors/origin
Robert T. Braden and S. Wolfe, UCLA Campus Computing Network
Other/unofficial uses
none known; no modern software uses port 73 for its assigned purpose
Security implications
negligible real-world exposure; NETRJS had no encryption (terminal IDs + UCLA accounts only); not seen in current threat intelligence; a listening port 73 today warrants investigation as unauthorized/misconfigured software; no specific CVEs or malware families found this pass
- RFC lineage
- RFC 88 (Jan 1971, initial spec), RFC 189 and RFC 599 (interim), RFC 740 (Nov 1977, authoritative, obsoletes 189/599), RFC 1700 (Assigned Numbers, documents 71–74) [Confirmed] — RFC 740, RFC 88, RFC 1700
- Analyst note
- An open port 73 is statistically rare and historically tied to obsolete ARPANET batch processing — treat as an anomaly and investigate; legitimate use is unlikely.
About port 73/udp.
Port 73/udp is registered with IANA as netrjs-3 with the description "Remote Job Service," and — like most ARPANET-era assignments — it carries no assignee, contact, registration date, or RFC reference in the current registry row; it is dual-registered on both TCP and UDP (73/tcp and 73/udp share the same netrjs-3 name and "Remote Job Service" description). The name traces to NETRJS, a network remote-job-entry protocol built by UCLA's Campus Computing Network (CCN) to submit batch jobs to its IBM 360 Model 91 mainframe over the early ARPANET. NETRJS defined three "contact sockets," one per character encoding: port 71 = EBCDIC, port 73 = ASCII-68, and port 75 = ASCII-63 — so netrjs-3 is specifically the ASCII-68 variant. A client opened a Telnet-style operator console session on the contact socket, after which the protocol established additional channels for card-reader input and printer/punch output. The protocol is documented in RFC 740 (NETRJS Protocol, 1977), with earlier history in RFC 88 and RFC 189 (both 1971) and RFC 325. For an analyst, port 73/udp is essentially dead legacy: NETRJS targeted a single institutional mainframe and never saw broad adoption, no modern operating system or application ships a listener on this port, and the IANA registration persists only for historical continuity. Real-world exposure is negligible — nmap-services records an empirical UDP frequency of ~0.000428, far outside the default scan list, and internet-wide scanners report no meaningful host population. No CVEs, malware families, or active exploitation campaigns target this port; UDP scanning of it is also inherently unreliable (a silent open port is indistinguishable from packet loss), so a "responsive" 73/udp is far more likely scan noise than a live legacy service.
- IANA assignment
netrjs-3— "Remote Job Service"; reference (blank — no RFC cited in IANA registry); assignee blank; dual-registered 73/tcp + 73/udp [Confirmed] — IANA Service Name and Transport Protocol Port Number Registry (the IANA Service Name and Transport Protocol Port Number Registry, rows 170/171)- Range class
- well-known (0–1023) [Confirmed]
- Prevalence
- nmap-services UDP open-frequency ≈ 0.000428 (well outside the default 1,000-port list); no meaningful Shodan/internet-wide population [Likely] — Nmap documentation
- Related ports
- NETRJS socket family 71 (netrjs-1, EBCDIC) and 75 (netrjs-4, ASCII-63); contrast modern batch/job-submission and RJE successors
- IANA Reference
- blank — the registry row carries no RFC reference even though the protocol itself has documented RFCs (74-series); do not conflate the two [Confirmed]
Primary use
NETRJS contact socket for ASCII-68 remote batch job entry to UCLA CCN's IBM 360/91 over ARPANET; sibling sockets 71 (EBCDIC) and 75 (ASCII-63); documented in RFC 740 (1977), with RFC 88/RFC 189 (1971) and RFC 325 history
Other/unofficial uses
none known; no surviving production implementations
Security implications
no documented CVEs, malware families, or exploitation campaigns; AuditMyPC reports no virus/trojan association; treated as dead legacy noise and safe to firewall-block with no modern service impact
Typically seen on
nothing in modern use; an open 73/udp is far more likely UDP scan noise (no handshake to confirm state) than a live service
- Analyst note
- An open port 73/udp is statistically rare and has no legitimate modern role; treat it as scan noise, a decoy, or an anomaly worth investigating rather than a normal service.
Service assignments.
| Name | Protocol | Description | Open frequency |
|---|---|---|---|
| netrjs-3 | UDP | Remote Job Service | 0.04% |
| netrjs-3 | TCP | Remote Job Service | 0.00% |
Service assignments from the IANA Service Name and Transport Protocol Port Number Registry, with open-frequency data from nmap-services.