143

Port 143/tcp carries the Internet Message Access Protocol, the server-side mailbox access protocol that lets clients leave mail on the server and synchronize state — read/unread, flagged, folder structure — across multiple devices. That synchronization model is what distinguishes IMAP from POP3, which is oriented toward downloading mail to a single device. IMAP is a stateful, tagged command/response protocol moving through Not-Authenticated, Authenticated, Selected, and Logout states, with operations like SELECT, FETCH, SEARCH, STORE, and IDLE (push-style notification). On port 143 a session begins in cleartext and may upgrade to TLS via STARTTLS; the current specification, RFC 9051 (IMAP4rev2, 2021, which obsoletes RFC 3501), requires TLS for any connection that carries credentials and advertises LOGINDISABLED on cleartext connections until TLS is negotiated. The core risk on 143 is that, without TLS, credentials and message contents traverse the network in plaintext and are exposed to sniffing on shared or public networks; STARTTLS on IMAP also has a documented command-injection history (CVE-2011-0411 / CVE-2011-1926). Most major providers now refuse cleartext logins on 143 and steer clients to implicit TLS on 993. For an analyst, an open 143/tcp suggests an IMAP mailbox server; confirm that STARTTLS is required and LOGINDISABLED is advertised before TLS, and flag any server that accepts a cleartext LOGIN.

IANA assignment

imap — "Internet Message Access Protocol"; reference [RFC3501][RFC9051]; assignee IESG/IETF Chair; modified 2021-02-22. (143/udp is Reserved, [RFC9051]) [IANA-assigned] — IANA Service Name and Transport Protocol Port Number Registry

Range class

well-known (0–1023)

Prevalence

nmap-services open-frequency 0.050420 [Well-established] — nmap-services file

Related ports

993 (IMAP over implicit TLS); SRV label _imap._tcp (RFC 6186)

Primary use

server-side mailbox access/synchronization; multi-device state sync

Other/unofficial uses

none notable beyond IMAP itself [n/a]

Security implications

cleartext credentials/content without TLS (sniffing on shared networks); STARTTLS command-injection history (CVE-2011-0411 / CVE-2011-1926); most providers now refuse cleartext 143

Typically seen on

IMAP mailbox servers (Dovecot, Cyrus, Courier, Exchange)

Analyst note

Open 143/tcp suggests an IMAP mailbox server. Confirm STARTTLS is required and LOGINDISABLED is advertised pre-TLS; flag any server accepting cleartext LOGIN.

Port 143/udp carries no service name in the IANA Service Name and Transport Protocol Port Number Registry and is explicitly marked "Reserved," with a modification date of 2021-02-22 tied to RFC 9051. This is the deliberate counterpart to 143/tcp, which is the active assignment for imap (Internet Message Access Protocol), referenced to [RFC3501][RFC9051], with assignee [IESG] and contact [IETF_Chair]. When RFC 9051 (IMAP4rev2) refreshed the registration, the UDP slot for the same number was reserved rather than assigned, because IMAP cannot run over UDP: RFC 9051 specifies that IMAP operates over "a reliable data stream such as that provided by TCP," and the protocol's stateful command/response sequencing, tagged responses, and folder-state synchronization depend on in-order, reliable delivery that UDP's connectionless model does not provide. No mainstream software targets 143/udp — IMAP servers (Dovecot, Cyrus IMAP, Microsoft Exchange) and clients (Thunderbird, Apple Mail, Outlook) use 143/tcp for plaintext/STARTTLS or 993/tcp for implicit TLS (IMAPS), never the UDP port. For an analyst, the practical takeaway is that a correctly configured host should not respond on 143/udp at all. Scanning activity that public trackers (SANS ISC) report against "port 143" is aggregated across transports and is driven by IMAP reconnaissance and credential-stuffing against the TCP service; any genuine 143/udp traffic is best read as scanner noise, mis-sent packets, or UDP port-sweep fallout, and a host that does answer on 143/udp warrants investigation as anomalous. Historical IMAP CVEs (for example CVE-2007-1675, an IMAP CRAM-MD5 buffer overflow in IBM Lotus Domino) apply to the TCP service only.

IANA assignment

blank service name; description "Reserved"; transport UDP; reference [RFC9051]; modification date 2021-02-22; registration date blank (not populated by IANA for this row) [Confirmed] — IANA Service Name and Transport Protocol Port Number Registry (the IANA Service Name and Transport Protocol Port Number Registry, 143/udp row)

Range class

well-known (0–1023)

Related ports

143/tcp (imap, active); 993/tcp (imaps, implicit TLS); the mail-retrieval cluster (110 POP3, 995 POP3S)

Primary use

none — 143/udp is Reserved with no protocol assignment; IMAP requires a reliable stream (TCP) per RFC 9051 and is incompatible with UDP

Common software

none uses 143/udp; IMAP stacks target 143/tcp (plaintext/STARTTLS) or 993/tcp (implicit TLS / IMAPS)

Exposure / scanning

SANS ISC tracks ongoing scanning on "port 143," but the data aggregates TCP+UDP and is driven by IMAP banner-grabbing / credential-stuffing recon against 143/tcp; no UDP-specific scanning pattern or exploit campaign is documented for 143/udp; probe traffic on the UDP port is most likely scanner noise or port-sweep fallout

TCP dual-registration

143/tcp is the active imap assignment — "Internet Message Access Protocol," references [RFC3501][RFC9051], assignee [IESG], contact [IETF_Chair], modification date 2021-02-22; the UDP port was reserved, not assigned [Confirmed] — IANA registry (143/tcp row)

Security recommendation

firewall/drop 143/udp at the perimeter — no legitimate service should listen there; any response on 143/udp is anomalous and worth investigating. For the TCP service, prefer IMAPS on 993/tcp with implicit TLS, or enforce STARTTLS, over cleartext 143/tcp [Confirmed/Likely] — RFC 9051, SANS ISC

Analyst note

143/udp is a reserved placeholder, not a service. Treat any live 143/udp responder as anomalous; the real attack surface and CVE history sit on 143/tcp.