MBP 1,1-10,2 The End of an Era: iCloud no longer Available for Apple Mail (Squid is helpless)

[maverick28]

The issue sprang up around June 24-25, the time that matched Apple's system status report, concerning the iCloud Mail outage. The latest received messages in both iCloud accounts of mine are dated June 24. Since that day, iCloud is no more.
I spent the entire week with ChatGPT trying painstakingly every potentially sound and viable solution - all in the realm of open-source Unix utilities, of course.

AI helped forge a smart strategy, revolving around the idea of tunnelling IMAP responses (since the disruption occurred with Incoming Mail: SMTP shows up as being online) through a custom local port. It purported to make up for irregularities that arose from what it diagnosed as being caused by missing legit root CA certificates on my machine, notably USERTrust by Sectigo. Restoring even the downloaded verified copy on Mac isn't possible since this troubled cert must be in SystemRootsCertificates.keychain, and macOS forbids meddling with this keychain. Drawing on newly downloaded copies of root and intermediate cert, the two forming a legitimate chain (USERTrust + Apple Public Server CA 1 G 11), combined with locally generated private key and dummy certs, it was thought to spoof Apple Mail to not bother checking the validity of UserTrust.

No way.

The brunt of these tasks fell on a utility called stunnel.

The plan was simple, yet elegant. stunnel was to:

Terminate TLS from Mail.app

Connect securely to imap.mail.me.com:993

Avoid certificate/trust problems (e.g., USERTrust issues)

Provide Mail.app with a clean local connection endpoint, e.g., localhost:1993

The last point was where it faltered. AI suggested the following (it may be of interest to active members of this forum and users of old macOS, such as Mavericks, which was the testbed of anything laid out below; credit goes to ChatGPT):


# Outline

Squid’s SSL bump is primarily affecting HTTP/HTTPS traffic (like rich content in emails or web browsing). It might be interfering if Mail's configuration ever ended up redirecting IMAP traffic through it, but normally Mail’s IMAP (port 993) would be separate.

stunnel’s purpose here is to isolate and reliably handle the TLS termination for Mail’s IMAP connection. If Apple changed something about the TLS parameters on their iCloud IMAP servers (which seems likely if Mail stopped working), using stunnel to manage that connection separately can make a significant difference.

Even if Mail was indirectly affected by Squid's handling of HTTPS (for embedded images, etc.), stunnel addresses the core mail protocol (IMAP) which is a different channel. This separation can help ensure that Mail either connects properly or fails consistently in one area, rather than mixing protocols with conflicting termination setups.

So yes—if your issue with iCloud connectivity is primarily with IMAP/TLS, employing stunnel to isolate and correctly terminate that traffic should help. It creates a dedicated, controlled environment for Mail’s non-web traffic, which is likely to restore connectivity if the problem stems from a certificate/trust chain mismatch introduced by external changes.

# Underperformance analysis and suggestions

stunnel.conf is set up correctly to perform a full TLS client connection to imap.mail.me.com:993, and listen locally on 127.0.0.1:1993 as an SSL-wrapped IMAP server.

But the problem is Mail.app (and openssl s_client) are sending a TLS ClientHello — which is wrong because your stunnel listener on 1993 is already decrypting TLS. That port expects plaintext IMAP — the same as what Apple Mail would speak after negotiating TLS.

Therefore, Apple Mail must be configured to use no SSL for localhost:1993, since TLS is already handled by stunnel.

# Failure analysis (testing involved openssl and other networking tools)

Why OpenSSL fails

When you run:

openssl s_client -connect localhost:1993

…it sends a TLS ClientHello — but the stunnel listener at 1993 expects raw IMAP, not a TLS handshake.

Hence the error:

SSL routines:tls_get_more_records, packet length too long

It’s like trying to speak encrypted to someone already decrypting — they hear gibberish.

# Connection Doctor

You're seeing:

AUTHENTICATE PLAIN

in Connection Doctor logs, and:

openssl s_client -connect localhost:1993
...
error:...SSL routines:tls_get_more_recordsacket length too long

These both confirm the issue:

Apple Mail is still trying to use SSL on port 1993

Despite unchecking “Use SSL” in the account settings, Apple Mail is wrapping the connection in TLS anyway. That’s why:

stunnel receives plaintext IMAP from iCloud.

But Apple Mail sends a TLS handshake, which stunnel forwards unmodified — iCloud’s IMAP server, expecting plaintext, breaks with packet length too long.

The week of troubleshooting ended with AI bringing up Apple overhauling the entire authentication framework, which inevitably impacted the iCloud platform. The factor of 2FA, 2-step, or, equally, the absence thereof was proved negligible. With Apple tightening screws and deploying even harsher if not more sophisticated and controlled security infrastructure, all familiar methods seem to not leave even the slightest mark once they decided to phase you out.

Practically, as of this minute, I've been cut off from my iCloud mail messages completely. Google's still operating normally.

 

[davigarma]

Thanks. We are completely banned from Icloud

 

[GalacticStag]

psst. wowfunhappy made this! There's a method to fix iCloud mail in it. I had some issues initially but iCloud Mail wasn't one of them! https://forums.macrumors.com/thread...0-6-10-9.2459969/?post=33990630#post-33990630

 

[eyoungren]

The issue sprang up around June 24-25, the time that matched Apple's system status report, concerning the iCloud Mail outage. The latest received messages in both iCloud accounts of mine are dated June 24. Since that day, iCloud is no more.
I spent the entire week with ChatGPT trying painstakingly every potentially sound and viable solution - all in the realm of open-source Unix utilities, of course.

AI helped forge a smart strategy, revolving around the idea of tunnelling IMAP responses (since the disruption occurred with Incoming Mail: SMTP shows up as being online) through a custom local port. It purported to make up for irregularities that arose from what it diagnosed as being caused by missing legit root CA certificates on my machine, notably USERTrust by Sectigo. Restoring even the downloaded verified copy on Mac isn't possible since this troubled cert must be in SystemRootsCertificates.keychain, and macOS forbids meddling with this keychain. Drawing on newly downloaded copies of root and intermediate cert, the two forming a legitimate chain (USERTrust + Apple Public Server CA 1 G 11), combined with locally generated private key and dummy certs, it was thought to spoof Apple Mail to not bother checking the validity of UserTrust.

No way.

The brunt of these tasks fell on a utility called stunnel.

The plan was simple, yet elegant. stunnel was to:



The last point was where it faltered. AI suggested the following (it may be of interest to active members of this forum and users of old macOS, such as Mavericks, which was the testbed of anything laid out below; credit goes to ChatGPT):


# Outline


# Underperformance analysis and suggestions



# Failure analysis (testing involved openssl and other networking tools)



# Connection Doctor




The week of troubleshooting ended with AI bringing up Apple overhauling the entire authentication framework, which inevitably impacted the iCloud platform. The factor of 2FA, 2-step, or, equally, the absence thereof was proved negligible. With Apple tightening screws and deploying even harsher if not more sophisticated and controlled security infrastructure, all familiar methods seem to not leave even the slightest mark once they decided to phase you out.

Practically, as of this minute, I've been cut off from my iCloud mail messages completely. Google's still operating normally.

I'm very sorry for your loss. I have three iCloud emails, none connected to anything other than my iPhones and iPad and never used - except when Apple emails me.

I've had Yahoo since 1999. I have three Google accounts, a work email (also Google) and my ISP email. My ISP email uses…Yahoo.

I've used Microsoft email apps since 1999. I hate Apple Mail. Fortunately, I never bought in to Apple's ecosystem.

 

[maverick28]

Apple Mail is a pest. It won't give in to even the most elaborate and legitimate debugging schemes that would pass with other applications, such as Thunderbird. For example, it won't bow to tunnelling its traffic through a proxy to enable IMAP command logging. That would allow us to explore its inner workings and figure out what clogs traffic, aborting SSL handshakes or something similar. However, Apple Mail was designed to break all the connections at the first sight of the MITM-listening from the ground up. It's a dead end.

What intrigues me is whether the issue hit all those Mavericks users who use iCloud mail or just a segment.

Another headache is that it won't allow write access to the SystemRoots keychain to add an updated root certificate. That might solve the problem, suggesting it arises at the higher IMAP level rather than the lower TCP one. The latter completes successfully (i.e., connection is established and the socket to an IMAP server is opened), while the IMAP server "greeting" is broken or intentionally refused.

The root cert, as the most probable culprit, is confirmed when I run

openssl s_client -connect imap.mail.me.com:993 -CAfile /path/to/valid/root/certificate.pem

I get the entire cert chain qualified and verified. As soon as I omit the "-CAfile" param, it reports a local cert (the root one) missing. It's impossible to force Apple Mail to use certificates of my choice. This is one of the vectors of control that Apple employs to promote its systems and coerce users to upgrade the OS.

 

[Wowfunhappy]

However, Apple Mail was designed to break all the connections at the first sight of the MITM-listening from the ground up.

...it's really not. As best I can tell nothing on OS X 10.9 uses any kind of certificate pinning. I used to think it did but it was just me being stupid.

The reason IMAP won't use your proxy is because it doesn't use HTTP. AquaProxy includes an IMAP proxy which is why it works.

Another headache is that it won't allow write access to the SystemRoots keychain to add an updated root certificate.

Please don't do this. I am not aware of any app that trusts the SystemRoots but not the user installed system keychain (Apple Mail definitely does not do this) so I would be suprised if such an app exists. You're just getting your system into a bad and possibly broken state for no good reason.

 

[f54da]

You do have write access to system roots keychain btw. I don't remember the exact details, but iirc from the keychain access UI you can delete certs, and from the CLI you can add certs (-k /System/Library/Keychains/SystemRootCertificates.keychain).

 

[Wowfunhappy]

iirc from the keychain access UI you can delete certs

At least for me, the UI does not seem to allow this, unless I'm missing something. I can set a certificate to untrusted but I can't delete it. Which makes sense IMO.

 

[f54da]

Idk I'm pretty sure you can actually delete it some way or another since I remember needing to do so to work around an old openssl bug. The menu item is grayed out but you just hit the delete key from what I recall.

https://community.jamf.com/general-...oot-certificates-is-probably-a-bad-idea-23732 corroborates that it worked at one point
>System Roots are special. Several years ago Apple blocked the ability to delete System Root certificates in Keychain Access. You can select them, you can view details, but, even with SIP disabled, selecting & hitting the delete key simply yields your favorite alert tone. (I have always been a "Morse" guy...)