IMAP Connection Refused

What is the "IMAP Connection Refused" error?

"Connection refused" is not an IMAP protocol response — IMAP servers reply with tagged OK, NO, or BAD lines, never "connection refused." It is a TCP/socket-layer error that happens before any IMAP conversation begins. At the operating-system level it surfaces as ECONNREFUSED (or "Connection refused"), and it means your client's SYN packet reached the host, but the host answered with a TCP RST (reset) instead of completing the handshake.

This is important because it tells you exactly where the problem is: the host is reachable, but nothing accepted the connection on the port you tried. That distinguishes it from two look-alike failures:

• Connection timed out (ETIMEDOUT) — no response at all, usually a wrong host, dropped packets, or a firewall silently discarding traffic.
• TLS/handshake errors — the TCP connection did succeed, but encryption negotiation failed (wrong port for the TLS mode, expired cert, etc.).

What causes IMAP Connection Refused?

1. Nothing is listening on that port. The IMAP daemon (Dovecot, Cyrus, Courier-IMAP, Exchange IMAP, etc.) is stopped, crashed, or bound to a different interface/port.
2. Wrong port for the encryption mode. IMAP uses port 143 for cleartext/STARTTLS and port 993 for implicit TLS (IMAPS). Per RFC 8314, implicit TLS on 993 is the recommended default. Connecting to a port the server isn't serving (e.g. 993 when only 143 is enabled) yields a refusal.
3. A firewall is actively rejecting (not dropping) the packet. A REJECT rule, security group, or ISP block returns an RST, which your client sees as "refused." (A DROP rule would instead cause a timeout.)
4. Your source IP is blocked. Fail2ban-style intrusion-prevention or host-based ACLs can blacklist an IP after failed logins and reset its connections.
5. Service binding / proxy misconfiguration. The IMAP service is listening only on 127.0.0.1, or a reverse proxy / load balancer in front of it has no upstream.

How do I fix IMAP Connection Refused?

Work outward from the client to the server:

1. Confirm host and port. Use the documented values for your provider, and match the port to the encryption mode: 993 for SSL/TLS (implicit), 143 for STARTTLS/plaintext.

2. Test the raw TCP connection (this isolates the socket layer from IMAP/TLS):

# Plain reachability test — does the port accept a connection?
nc -vz imap.example.com 993

# Or with openssl for a 993 (implicit TLS) endpoint:
openssl s_client -connect imap.example.com:993 -crlf

nc reporting "Connection refused" confirms the RST; "succeeded"/a TLS banner means the port is open and you should look at credentials or TLS instead.

3. On the server, verify the daemon is listening:

# Is something bound to 143/993 and on which interface?
ss -tlnp | grep -E ':143|:993'
systemctl status dovecot   # or cyrus-imapd / courier-imap

If it's bound only to 127.0.0.1, change the listen address to the public/LAN interface and restart.

4. Check firewall and IP-block rules. Confirm 143/993 are allowed inbound (host firewall, cloud security group, ISP). Look for an IP ban from fail2ban or similar:

sudo fail2ban-client status dovecot

5. Read the logs on both sides — the mail server log (e.g. /var/log/mail.log) and your client's debug output — to confirm whether the refusal is a missing listener, a firewall reset, or an IP block.