5

Port 5/tcp is registered with IANA as rje with the description "Remote Job Entry," assignee Jon Postel, and a blank reference field (dual-registered on TCP and UDP). Remote Job Entry is the early-network procedure for submitting non-interactive batch jobs from a remote workstation to a host: a user sends a Job Control Language deck over the network, the host queues and runs the job, and the output is returned later. Socket 5 was designated the standard "RJE Logger" contact point in RFC 407 (October 1972), one of the original ARPANET application protocols alongside Telnet and FTP — a User TELNET process connected to socket 5 via the Initial Connection Protocol to start an RJE session, with control flowing over a TELNET connection and the actual job input/output moving over FTP. The IANA reference field is blank: although RFC 407 is the historical specification that defined the socket, it is not cited as a reference in the current IANA port record, and no registration or modification date is recorded there either. RJE itself traces to the IBM OS/360 batch era (HASP, and implementations such as UCLA's NETRJS), and its peer-to-peer successor, Network Job Entry (NJE) in IBM JES2/JES3 environments, later moved to TCP/IP but uses different ports rather than port 5. For an analyst the practical takeaway is that port 5/tcp is effectively defunct: there is no actively maintained modern software documented to bind it for RJE, it does not appear among the most-scanned ports in current Shodan data, and no CVEs are tied to the RJE service on this port. Nmap's service database still carries the rje label for identification only. A responsive port 5 on a modern host is therefore an anomaly — most plausibly a legacy or misconfigured system, a decoy, or some coincidental non-RJE service binding the number — and is worth investigating rather than assuming a legitimate RJE service.

IANA assignment

rje — "Remote Job Entry"; reference (blank — no RFC cited in IANA registry); assignee Jon Postel; dual-registered 5/tcp + 5/udp [Confirmed] — IANA Service Name and Transport Protocol Port Number Registry (the IANA Service Name and Transport Protocol Port Number Registry, line 12)

Range class

well-known (0–1023) [Confirmed]

Registration/modification date

not recorded in the IANA registry (blank); no third-party date asserted [Confirmed] — IANA registry (blank Date columns)

Prevalence

very low; 5/tcp does not appear among the most-scanned ports in current Shodan data (checked June 2026). A precise nmap-services open-frequency figure was not confirmed for this port [Likely] — Shodan data-status ports list

Related ports

the small/legacy well-known services cluster (7, 9, 11, 13, 17, 19, 37); 5/udp sibling; contrast modern job schedulers and NJE-over-TCP/IP

Primary use

standard "RJE Logger" contact socket for Remote Job Entry; User TELNET connects via the Initial Connection Protocol, control over TELNET and job data over FTP

Protocol heritage

batch job submission from the IBM OS/360 era (HASP; UCLA NETRJS); RJE is one of the original ARPANET application services; the NJE successor (IBM JES2/JES3) moved to TCP/IP but uses different ports

Other/unofficial uses

none documented; no current open-source or commercial product is recorded binding port 5 for RJE

Security implications

protocol is effectively obsolete; no CVEs are associated with RJE on port 5, and no documented active exploit, malware, or threat-actor campaign targets it. The original protocol was unencrypted, as was standard for ARPANET-era designs. An open port 5 today most likely indicates a legacy/misconfigured host, a decoy, or a coincidental non-RJE binding

Typically seen on

historically, mainframe/RJE workstation environments; on a modern host, an anomaly worth investigating

Analyst note

Port 5/tcp is essentially defunct. Treat a responsive port 5 as a legacy, decoy, or misconfiguration signal rather than a normal service, and investigate.

Port 5/udp is registered with IANA as rje with the description "Remote Job Entry," assignee and contact Jon Postel, and a blank reference field (dual-registered on TCP and UDP — 5/tcp carries the identical row). Remote Job Entry is a mainframe-era convention for submitting batch processing jobs from a remote terminal to a centralized host and retrieving their output, typically through a spool or line-printer system. It predates interactive computing and was built for non-interactive, asynchronous batch workloads. On IBM systems the lineage runs through OS/360 RJE, HASP (Houston Automatic Spooling Priority), the JES2/JES3 job entry subsystems, and RSCS (Remote Spooling Communications Subsystem); IBM later evolved this into Network Job Entry (NJE), which supports transport over TCP/IP. The IANA reference field is blank — no RFC or document is cited in the registry — and no registration date is recorded there either. The port-5 assignment is one of the original low-numbered ports tied to Jon Postel, the early IANA administrator, which reflects its pre-RFC-formalization origin rather than a current maintainer. The UDP assignment exists only to mirror the TCP one: RJE is connection-oriented in practice, and no distinct UDP use case is documented anywhere. For an analyst, port 5/udp is effectively obsolete: it is superseded by modern distributed processing and job-scheduling systems and sees no meaningful legitimate traffic on the public internet, so a responsive port 5 is best treated as an anomaly worth investigating rather than a normal service. Any surviving legacy RJE daemon could plausibly lack modern authentication, but that is a theoretical concern given the protocol's near-total absence from current deployments.

IANA assignment

rje — "Remote Job Entry"; reference (blank — no RFC cited in IANA registry); assignee/contact Jon Postel; dual-registered 5/tcp + 5/udp [Confirmed] — IANA Service Name and Transport Protocol Port Number Registry (https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.csv)

Range class

well-known (0–1023) [Confirmed] — port number < 1024

Registration date

Unknown — IANA does not publish one for this entry and no reliable third-party date was found [Unknown] — registry row has a blank Registration Date column

Prevalence

nmap-services observed open-frequency 5/udp ≈ 0.000593 (very low — roughly 6 in 10,000 scanned hosts in the nmap-services sample) [Confirmed] — nmap-services dataset; the dual-registered 5/tcp row records 0.000000 in the same dataset, so what little observed activity exists sits on the UDP side

[Confirmed] — nmap-services dataset

Related ports

5/tcp (rje — identical IANA registration); the small/legacy low-numbered cluster (1 tcpmux, 7 echo, 9 discard, 11 systat, 13 daytime, 17 qotd, 19 chargen)

Primary use

Remote Job Entry — submit batch jobs from a remote terminal to a centralized mainframe host and retrieve output; legacy/mainframe-era, connection-oriented in practice

Other/unofficial uses

none notable; associated software is the IBM batch lineage (OS/360 RJE, HASP, JES2/JES3, RSCS, NJE)

Security implications

effectively obsolete with near-zero modern usage; a surviving legacy RJE daemon could lack modern authentication (theoretical, given the protocol's near-total absence); no notable documented internet-wide scanning or exploitation activity found as of June 2026; standard hardening blocks unused low-numbered ports

Typically seen on

legacy/inherited mainframe or air-gapped environments; otherwise an anomaly on the modern internet

UDP-specific use

none documented — the UDP assignment mirrors TCP; RJE is inherently connection-oriented and has no distinct UDP use case [Likely] — https://en.wikipedia.org/wiki/Remote_job_entry, https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml

Analyst note

Port 5/udp is obsolete and sees no meaningful legitimate traffic. A responsive port 5 is statistically rare — treat it as an anomaly (legacy mainframe remnant, decoy, or misconfiguration) and investigate rather than assume normal RJE.