Very slow access top IMAP email

Spectrum email via IMAP is intermittently very slow or fails to connect, while Spectrum Webmail is instantaneous.

Affected server:

• mobile.charter.net
• IP: 47.43.18.12
• TCP port: 993

Observed behavior:

• Repeated TCP connection attempts to 47.43.18.12:993 intermittently fail or take 15–26 seconds.
• Packet capture shows SYN retransmissions at approximately 1, 3, 7, and 15 seconds before a SYN-ACK is finally returned.
• In some tests, about 30–40% of connection attempts failed completely after ~26 seconds.
• The problem occurs from more than one device on the same LAN.
• Rebooting the TP-Link ER605 router made no meaningful difference.
• DNS resolution is fast and consistently returns 47.43.18.12.
• Spectrum Webmail opens the same messages instantly.

Control tests from the same PC/network:

• outlook.office365.com:993 — 10/10 successful connections
• smtp.gmail.com:465 — 10/10 successful connections
• 1.1.1.1:443 — 10/10 successful connections

This appears to be a problem with the Spectrum network path to 47.43.18.12 or with the Spectrum IMAP front end itself, not an email-client configuration or authentication issue.

Please escalate to Spectrum network/email engineering rather than treating this as a normal mail-client setup problem.

====================================================

Based on the packet behavior we captured, my best educated guess is that Spectrum has a broken or overloaded front-end device in front of the IMAP service — likely a load balancer, firewall, TCP proxy, or some similar ingress component — rather than a problem with the IMAP application itself.

The important clue is the SYN behavior. In the bad connection, your PC sent SYNs at about 0, 1, 3, 7, and 15 seconds before finally receiving a SYN-ACK. That means the failure occurs before TLS and before IMAP.

That pattern is consistent with a few specific failure modes:

• Overloaded or unhealthy IMAP load balancer / TCP proxy. Some new TCP connection attempts simply aren't serviced, while others go through immediately.
• Firewall or SYN-protection malfunction. A stateful firewall or SYN-cookie mechanism may be intermittently dropping legitimate connection attempts.
• Bad member in a server pool. If 47.43.18.12 fronts several backend nodes, some connection attempts may hash to a dead or unhealthy backend while others hit a good one.
• Spectrum-internal routing / ECMP problem. Different flows can take different internal paths based on source/destination ports. One path may be impaired, which would explain why some connections work in 50 ms and others need several retransmissions.
• Less likely: rate limiting on IMAP connection creation. Your test pattern doesn't look like deliberate rate limiting, but a misconfigured DoS-protection system could produce something similar.

What makes the front-end/load-balancer theory especially plausible is that the server advertises itself as an older InterMail system, and Spectrum has already had recent IMAP-side incidents where webmail worked while external IMAP clients failed. In June, Spectrum moderators explicitly escalated a mobile.charter.net problem to engineering, and after an update said it had been tied to another ongoing email issue and “may have been a little more than just a certificate.”

I would not guess that the actual mailbox storage or IMAP daemon is overloaded. If that were the main problem, I would expect TCP to establish normally and the delay to occur after login or during SELECT, FETCH, etc. Your capture shows packets disappearing at the TCP handshake stage.

The most likely architecture is something roughly like:

Internet
   |
Spectrum edge network
   |
Firewall / DDoS protection
   |
Load balancer / TCP proxy
   |
InterMail IMAP servers

My bet is on the firewall/load-balancer layer or one unhealthy path/member behind it.

The fact that this appears to have recurred over time suggests Spectrum may have a brittle or aging external-mail-access infrastructure rather than a single transient outage. Their June incident affected multiple client types and required an engineering-side change.

If Spectrum engineering actually looks at your case, the most useful thing for them is the exact signature:

SYNs to 47.43.18.12:993 are intermittently unanswered for 1/3/7/15-second retransmission intervals, while other TCP/993 destinations are clean.

That points them immediately toward their edge/load-balancer/firewall statistics, not user mail settings.