Port 143 IMAP – Free, Online, Private

What listens on 143

Port 143 is IMAP. The IANA name is imap, Internet Message Access, with RFC 3501 and RFC 9051 in the registry. The client leaves mail on the server and synchronizes folders. STARTTLS upgrades the cleartext session. Implicit TLS is port 993, imaps. The registry marks UDP 143 as reserved. Do not probe it for IMAP. IMAP is not a sending protocol. Outbound mail is SMTP submission. A host that only stores mail still needs 143 or 993, and it does not need 25 unless it also receives from other servers.

The IANA service name is imap: Internet Message Access. The practical transport is TCP. The checks below use TCP. IANA may also have a UDP row for 143. The service described here is the TCP one. A process can bind this port without being the service in the registry. The commands show who bound it. They do not prove the protocol on the wire is the one IANA named.

Service notes for port 143

Service notes for port 143: the IANA name is imap (Internet Message Access), and the program people mean is IMAP. TCP 143 is the IANA imap port, cleartext IMAP. IMAP over TLS is 993, and UDP 143 is reserved. Cleartext IMAP exposes the password and the mail if STARTTLS is not required. Configure the daemon to refuse login before TLS, or close 143 and serve only 993. Certificate verification matters. A client that accepts any certificate on 143 after STARTTLS is not protected. An admin panel on the same host is not IMAP and should not be bolted onto this port. If you do not host mail, a listener on 143 is a package you did not mean to enable. Nothing in that paragraph applies to a different number just because the software family is similar. If your listener is not on 143, you are on the wrong page.

Clients set 'IMAP port 143, SSL' and then speak TLS to a cleartext port. The banner is * OK, not a TLS record, and the client says the certificate failed or the server is not responding. Use 993 for implicit TLS. A second bug is a firewall that opened 143 years ago and never opened 993 after you required TLS. A third is IDLE connections being killed by a middlebox that thinks a quiet TCP session is dead. The port is fine. The timeout is the bug.

How to check whether it is open

On the machine itself, ask the kernel which socket is bound. ss and lsof do that. A firewall, a security group, and a Docker publish rule sit in front of that socket, so a listener is not the same thing as a port the internet can use. From somewhere else, nc -vz host 143 tries a TCP handshake when the command is the TCP form. A refusal means something answered with a reset. A timeout means a filter dropped the packet or the host is unreachable. Those are different faults. A banner beginning with * OK is IMAP. nc -vz host 143 is the TCP test. For TLS, test 993 with a TLS client. UDP is reserved and a UDP probe is noise.

grep and findstr match text. A pattern of :80 also matches :8080 and :8000. The lsof and Get-NetTCPConnection forms take a numeric port and do not have that substring bug. Use them when the number is ambiguous. ss filters in the kernel with sport = :N, which is also exact. On macOS, netstat -p selects a protocol. It does not print the process the way Linux netstat -p does. lsof prints the process.

• Port 993 is imaps. Port 143 is cleartext plus optional STARTTLS.
• UDP 143 is reserved in the registry, not an IMAP transport.
• IMAP does not deliver mail to other servers. That is SMTP on 25.
• A * OK banner is not proof that your account can log in.

Linuxsudo ss -lptn 'sport = :143'
sudo lsof -nP -iTCP:143 -sTCP:LISTEN

macOSsudo lsof -nP -iTCP:143 -sTCP:LISTEN
netstat -anv -p tcp | grep '\.143[^0-9]'

Windowsnetstat -ano | findstr :143
Get-NetTCPConnection -LocalPort 143

Remotenc -vz host 143