57

Port 57/tcp is registered with IANA with the description "any private terminal access," assignee Jon Postel, a blank service-name field (no short IANA service name is assigned), and a blank reference field; it is dual-registered on TCP and UDP. The "any private terminal access" wording is the same placeholder language IANA uses elsewhere (cf. 56) to mark a number that is set aside for unspecified private use rather than bound to a published, interoperable service — so the current registry entry deliberately names no real protocol. The historically interesting fact for an analyst is what port 57 *used* to carry: the Mail Transfer Protocol (MTP), an early ARPANET email protocol specified in RFC 772 (S. Sluizer and J. Postel, ISI, September 1980), which states plainly that "this protocol is assigned the service port/socket 57 (71 octal)." MTP was a direct precursor to SMTP, structurally close to FTP, using a small command-response vocabulary (MAIL, MRCP, MRSQ, MEND/QUIT, NOOP) over a connection on port 57. RFC 772 was obsoleted by RFC 780 (Sluizer and Postel, May 1981), which kept port 57; RFC 780 was in turn obsoleted by RFC 788, and the line eventually gave way to RFC 821 (SMTP) in 1982, which moved mail onto port 25 where it remains. MTP is completely obsolete — there are no surviving implementations — and the modern IANA registration no longer references it; the early RFCs in this chain (e.g. RFC 780) now carry a "Legacy" designation and "no formal standing" at the IETF. For an analyst, port 57 is essentially never a legitimate listening service today: there is no recognized modern software bound to it and it is not part of Nmap's default top-1000 set, so any traffic on 57/tcp should be treated as anomalous (port scanning, misconfiguration, or a custom/obscure private application) rather than a normal service. No CVEs, scan campaigns, or threat reports specific to port 57 were found in available sources as of June 2026, so the security relevance is the generic "unexpected open port" signal, not a known exploit.

IANA assignment

service name blank (no short name registered) — description "any private terminal access"; reference (blank — none cited in IANA registry); assignee/contact Jon Postel; dual-registered 57/tcp + 57/udp [Confirmed] — the IANA Service Name and Transport Protocol Port Number Registry lines 122–123; https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml

Range class

well-known (0–1023) [Confirmed]

Registration date

Unknown — no registration or modification date is published by IANA for port 57; third-party "date registered" values are database artifacts, not authoritative [Unknown] — the IANA Service Name and Transport Protocol Port Number Registry line 122 (date columns blank)

Related ports

25/tcp (SMTP, the successor to MTP); the adjacent registry neighbors 56 (XNS Authentication) and 58 (XNS Mail)

Primary use

none currently published — registry value is the placeholder "any private terminal access," i.e. set aside for unspecified private use rather than bound to an interoperable service

Common software

Unknown — no known modern software actively binds port 57/tcp; MTP (pre-1982) has no surviving implementations [Unknown]

Security implications

negligible internet exposure; not in Nmap's default top-1000 ports; no port-57-specific CVEs, scan campaigns, or threat reports found as of June 2026. Because MTP is obsolete and the current registration is only the "any private terminal access" placeholder, port 57 is not a recognized attack surface — any traffic is anomalous and worth investigating (scan, misconfiguration, or custom private app)

Typically seen on

nothing in modern use; an open 57/tcp is an anomaly

Historical use

Mail Transfer Protocol (MTP), an early ARPANET email protocol assigned port 57 by RFC 772 ("this protocol is assigned the service port/socket 57 (71 octal)"); precursor to SMTP, structurally close to FTP; obsolete with no surviving implementations [Confirmed] — RFC 772 (Sluizer & Postel, Sept 1980); RFC 780 (May 1981); https://datatracker.ietf.org/doc/rfc772/ , https://www.rfc-editor.org/rfc/rfc780.html

RFC lineage

RFC 772 (Sept 1980, MTP, assigned port 57) → obsoleted by RFC 780 (May 1981, retained port 57) → obsoleted by RFC 788 → superseded by RFC 821 (SMTP, port 25, 1982). RFC 780 is flagged "Legacy" with no formal standing at the IETF

[Confirmed] — https://datatracker.ietf.org/doc/html/rfc780 ; https://datatracker.ietf.org/doc/html/rfc821

Analyst note

Treat an open port 57 as anomalous. There is no legitimate modern listener; the only substantive history is the obsolete MTP, and IANA today records only a private-use placeholder.

Port 57/udp is listed in the IANA Service Name and Transport Protocol Port Number Registry with the description "any private terminal access," an empty service-name column, assignee and contact both [Jon_Postel], and blank registration-date, modification-date, and reference fields (dual-registered on TCP and UDP). It is not a real protocol assignment so much as a reservation from the early IANA era: the earliest published record is RFC 1340 "Assigned Numbers" (Reynolds & Postel, July 1992), which lists both 57/tcp any private terminal access [JBP] and 57/udp any private terminal access [JBP], where [JBP] is Jon B. Postel. RFC 1340 is long obsolete (superseded by later Assigned Numbers RFCs and ultimately the online IANA registry), but the wording carried forward unchanged, and the IANA Reference column for this entry stays blank — there is no RFC standardising a protocol here. No specific application or service was ever standardised on port 57, and no widely deployed software is known to use 57/udp as a primary port; the label "priv-term" seen in some port databases is an informal service-name shorthand, not an IANA service name. For an analyst the practical meaning is that 57/udp is a reserved-but-empty number that is virtually always closed: there is no documented malware or trojan historically associated with it in the major databases, and the one security-relevant note is that the FX-Tools scanner sends non-standard packets to the (typically closed) port 57 as an OS-fingerprinting probe, inferring host characteristics from the closed-port response rather than attacking any running service. Because nothing legitimately listens here, unexpected inbound 57/udp traffic is far more likely to be probe or scanner noise than exploitation of a service.

IANA assignment

service-name column blank — "any private terminal access"; reference (blank — no RFC cited in IANA registry); assignee/contact both [Jon_Postel]; dual-registered 57/tcp + 57/udp [Confirmed] — IANA Service Name and Transport Protocol Port Number Registry (the IANA Service Name and Transport Protocol Port Number Registry)

Range class

well-known (0–1023) [Confirmed]

Registration / modification date

blank in the IANA registry — Unknown (reported null, not fabricated; IEEE/IANA publish no date for this entry) [Confirmed] — IANA CSV

Related ports

57/tcp (same description/assignee); the early-reservation cluster of low well-known numbers

Primary use

none — no protocol or application standardised; "any private terminal access" is a placeholder-style reservation from the early IANA era

Other/unofficial uses

"priv-term" appears in some port databases as an informal shorthand, not an IANA service name

Common software

Unknown — no widely deployed software is known to use 57/udp as a primary port; no IANA-registered application exists [Likely]

Security implications

not among commonly targeted well-known ports; FX-Tools sends non-standard packets to the typically-closed port 57 for OS fingerprinting (closed-port response inference, not service exploitation); no documented malware/trojan association; near-universally closed, so inbound traffic is more likely probe/scanner noise

Exposure risk

Low — no known production services run on 57/udp; risk arises only from an unintended bind or misconfigured firewall allowing probes through [Likely]

Typically seen on

nothing in normal operation; an open 57/udp is an anomaly worth investigating

RFC history

appears in RFC 1340 (Reynolds & Postel, July 1992) as 57/udp any private terminal access [JBP]; RFC 1340 is now obsolete but the assignment carried forward unchanged [Confirmed] — RFC 1340

Analyst note

A responsive 57/udp is statistically rare and unexplained by any standard service — treat as anomaly, probe target, or an unintended local bind rather than a normal service.