50

Port 50/tcp is registered with IANA as re-mail-ck with the description "Remote Mail Checking Protocol," assignee Steve Dorner, and a blank reference field (dual-registered on TCP and UDP). The Remote Mail Checking Protocol (RMCP) is defined in RFC 1339 (June 1992; S. Dorner and P. Resnick, University of Illinois at Urbana-Champaign): it lets a client ask a mail server whether new or unread mail is waiting without retrieving any message content, which saved bandwidth and round-trips for resource-constrained clients of the era. A client sends a username — and, in the authenticated variant, a password — and the server returns timing data about the last mail delivery and the last read access, from which the client infers whether unseen mail exists. Worth flagging honestly: RFC 1339 specifies UDP as the transport, while the IANA registry dual-lists re-mail-ck on both UDP and TCP with identical metadata; the TCP entry is an administrative registration without a matching RFC specification, and the IANA reference column for the port is blank. RMCP predates the widespread dominance of POP3 and IMAP and was entirely displaced by them — POP3 (port 110) and IMAP (143/993) provide the same "is there new mail" signal as a side effect of full mailbox access — so the protocol is obsolete and has no known maintained implementation. Security-wise the design is plaintext with no encryption: the base variant exposes mailbox presence and timing for any enumerated username, and the authenticated variant adds a cleartext password exchange, but the practical attack surface is near-zero because no production software deploys RMCP. For an analyst, an open 50 is statistically rare and almost never a legitimate RMCP service; it is more plausibly a low-port scanner sweep, a crafted/misrouted packet, or a non-standard local use, and is worth investigating rather than treating as a normal mail service.

IANA assignment

re-mail-ck — "Remote Mail Checking Protocol"; reference (blank — no RFC cited in IANA registry); assignee Steve Dorner; dual-registered 50/tcp + 50/udp [IANA-assigned] — IANA Service Name and Transport Protocol Port Number Registry (the IANA Service Name and Transport Protocol Port Number Registry rows 109–110)

Range class

well-known (0–1023)

Prevalence

negligible real-world exposure; not among commonly scanned system ports in public scan analyses (de-facto, inferred) [Likely] — Shodan port data, threat-reference summaries

Related ports

110 (pop3), 995 (pop3s), 143 (imap), 993 (imaps), 109 (pop2)

Primary use

remote mail-status checking (RMCP, RFC 1339; obsolete)

Other/unofficial uses

none notable today

Security implications

plaintext, no encryption; base variant leaks mailbox presence/timing for enumerated usernames; authenticated variant adds a cleartext password; no known CVEs or malware families; superseded by POP3/IMAP; effectively never legitimately open

Typically seen on

essentially nothing in modern infrastructure; an open 50 is an anomaly (scanner sweep, crafted/misrouted packet, or non-standard local use)

Transport caveat

RFC 1339 specifies UDP; IANA dual-lists tcp+udp — the TCP entry has no matching RFC specification [Well-established] — RFC 1339, IANA registry

Analyst note

An open 50 is statistically rare and almost never legitimate RMCP; investigate it as a scan artifact, decoy, or misconfiguration rather than a normal service. Recommended posture is to block inbound 50 unless specifically required (essentially never).

Port 50/udp is registered with IANA as re-mail-ck with the description "Remote Mail Checking Protocol," assignee Steve Dorner, and a blank reference field in the registry (dual-registered on TCP and UDP under the identical service name). The protocol is defined in RFC 1339 (S. Dorner and P. Resnick, University of Illinois at Urbana-Champaign, June 1992; status Experimental). RMCP lets a mail client send a single UDP datagram to port 50 on a mail server to ask whether new mail has arrived for a given user, avoiding the cost of opening a full TCP connection: the client sends a 32-bit zero field followed by a username, and the server replies with three 32-bit numbers encoding time-since-last-message and time-since-last-read. Both an unauthenticated mode and a cleartext-password-authenticated mode were specified. The protocol was deliberately built on UDP to skip TCP connection setup, and UDP 50 is the sole registered service in this transport slot. RMCP never saw broad deployment; its narrow "do I have mail?" function was fully absorbed by POP3 (RFC 1939) and IMAP (RFC 3501), which add authentication, retrieval, folder management, and synchronization, so by the late 1990s RMCP was redundant. The registration survives in the IANA registry mainly as a historical artifact, and the RFC has never been updated or advanced beyond Experimental. The reason port 50 matters for an analyst is mostly disambiguation: UDP port 50/re-mail-ck is routinely confused with IP Protocol 50, which is the Encapsulating Security Payload (ESP) of IPsec — a completely separate numbering space. ESP operates at the IP layer and has no port of its own; when NAT traversal is needed it is wrapped in UDP port 4500 (RFC 3948), not UDP 50. For exposure, UDP 50/re-mail-ck carries essentially no legitimate modern traffic; RFC 1339 itself flagged metadata privacy and maildrop-existence disclosure (it advised servers to return identical responses for non-existent and empty maildrops to block enumeration) and the authenticated mode passes credentials in cleartext. No CVEs or active exploits are known to specifically target UDP 50/re-mail-ck, and it does not appear on commonly cited "top exposed UDP ports" lists, consistent with negligible deployment, so an analyst should treat a responsive UDP 50 as anomalous and block it inbound at the perimeter unless a legacy RMCP service is deliberately operated (effectively none today).

IANA assignment

re-mail-ck — "Remote Mail Checking Protocol"; reference (blank — no RFC cited in IANA registry, though the protocol is defined in RFC 1339); assignee Steve Dorner; dual-registered 50/tcp + 50/udp [Confirmed] — IANA Service Name and Transport Protocol Port Number Registry; the IANA Service Name and Transport Protocol Port Number Registry line 110 (0-indexed)

Range class

well-known (0–1023)

Prevalence

nmap-services observed open-frequency 50/udp ≈ 0.000428 (very low — roughly 4 in 10,000 scanned hosts in the nmap-services sample); the dual-registered 50/tcp side is rarer at ≈ 0.00005 [Confirmed] — nmap-services dataset; beyond that figure no broader internet-wide scanning data for UDP 50 was found in the public sources reviewed, and its absence from common top-exposed-UDP lists is consistent with negligible deployment [Likely]

Related ports/protocols

mail services POP3 110, IMAP 143; the legacy small-services cluster; contrast IP Protocol 50 (ESP) and UDP 4500 (IPsec NAT-T)

Primary use

lightweight UDP mail-arrival check (RMCP, RFC 1339, Experimental; rarely deployed) — single datagram queries whether new mail has arrived for a user

Protocol definition

RFC 1339 (S. Dorner, P. Resnick, June 1992), status Experimental — never updated or advanced

Other/unofficial uses

none known; no widely deployed modern client or server implements re-mail-ck

Security implications

obsolete; cleartext credentials in authenticated mode; RFC 1339 noted mail-metadata privacy and maildrop-existence disclosure (recommended identical responses for absent vs. empty maildrops to prevent enumeration); no known CVEs or active exploits for UDP 50/re-mail-ck; not on common "top exposed UDP ports" lists

Typically seen on

effectively nothing today; a responsive UDP 50 is anomalous and worth investigating

Common point of confusion

IP Protocol 50 = ESP (IPsec Encapsulating Security Payload), an IP-layer protocol with no port; ESP under NAT is wrapped in UDP 4500 (RFC 3948). Entirely separate numbering space from UDP port 50 [Confirmed] — strongSwan docs; SANS ISC

Superseded by

POP3 (RFC 1939) and IMAP (RFC 3501), which provide authentication, retrieval, and synchronization [Confirmed] — RFC 1339 use case

Analyst note

First disambiguate from IP Protocol 50 (ESP). Legitimate UDP 50/re-mail-ck traffic is essentially nonexistent; block inbound at the perimeter unless a legacy RMCP service is deliberately run.