IOS 17 Beta 2 unable to fetch IMAP mail

the same situation as in first beta :(

Third beta resolved problem

Here we are again:

FB13825638 (iOS 18 REGRESSION: Mail no longer accepts a self-signed certificate from my mail server (AGAIN))

Problem remains on iOS 18 beta 4 v2 (22A5316k). No change.

I hit the same issue with 22A5326f ...

Confirming this is still regressed in iOS 18.0 beta 5 (22A5326f)!

This is extremely concerning, as it is starting to appear that this regression is not going to be fixed.

Please file your own feedback report if you are hitting this problem (error -9,808) in the iOS 18 betas (feel free to reference FB13825638), as the more feedback received, the more likely Apple will be to fix the problem. If the appearance is that only a handful of users are affected, it will not be prioritized among the myriad of other problems that likely exist.

Aug 9 22:52:11 mailserver imaps[2613012]: starttls: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits reused) no authentication Aug 9 22:52:12 mailserver imaps[2613012]: client id sessionid=<mailserver.orion-1723258331-2613012-1-14041990500246658580>: "name" "iPhone Mail" "version" "22A5326f" "os" "iOS" "os-version" "18.0 (22A5326f)" Aug 9 22:52:14 mailserver imaps[2613012]: open: user user opened Notes Aug 9 22:52:32 mailserver imaps[2613029]: accepted connection Aug 9 22:52:32 mailserver master[2613040]: about to exec /usr/libexec/cyrus-imapd/imapd Aug 9 22:52:32 mailserver imaps[2613040]: Option 'tls_ca_file' is deprecated in favor of 'tls_client_ca_file' since version 2.5.0. Aug 9 22:52:32 mailserver imaps[2613040]: Option 'tls_cert_file' is deprecated in favor of 'tls_server_cert' since version 2.5.0. Aug 9 22:52:32 mailserver imaps[2613040]: Option 'tls_key_file' is deprecated in favor of 'tls_server_key' since version 2.5.0. Aug 9 22:52:32 mailserver imaps[2613040]: SQL backend defaulting to engine 'mysql' Aug 9 22:52:32 mailserver imaps[2613040]: zoneinfo_dir is unset, libical will find its own timezone data Aug 9 22:52:32 mailserver imaps[2613040]: ical_support_init: found 418 timezones Aug 9 22:52:32 mailserver imaps[2613040]: executed Aug 9 22:52:32 mailserver imaps[2613029]: tls_client_ca_dir=(NULL) tls_client_ca_file=/etc/pki/tls/certs/ca-bundle.crt Aug 9 22:52:32 mailserver imaps[2613029]: tls_server_cert=/etc/pki/cyrus-imapd/cyrus-imapd.pem tls_server_key=/etc/pki/cyrus-imapd/cyrus-imapd.pem Aug 9 22:52:32 mailserver imaps[2613029]: Set client CA list: Client cert requested, not required Aug 9 22:52:32 mailserver imaps[2613029]: TLS Server Name Indication (SNI) Extension: "localhost" Aug 9 22:52:32 mailserver imaps[2613029]: SSL_accept() incomplete -> wait Aug 9 22:52:32 mailserver imaps[2613029]: ssl/tls alert certificate unknown in SSL_accept() -> fail Aug 9 22:52:32 mailserver imaps[2613029]: imaps TLS negotiation failed: [192.168.1.249] Aug 9 22:52:32 mailserver imaps[2613029]: extractor_destroy((nil))

You can see that the notes are syncing as expected from the imap server but it's really just an imap issue when connecting to fetch mails ... I can sync notes but not mails !!!

So I tried with a selfsigned CA and generated a new certificate that I signed with that CA ... no dice, still the -9808 issue. I have the feeling the mail tls negociation might be broken somehow because of this :

Aug  9 23:11:30 mailserver imaps[2614724]: ssl/tls alert certificate unknown in SSL_accept() -> fail

There's definitely a bug with self-signed certificates but I've managed to make it work with a custom CA .

1. Create a new CA
2. Create a CSR for your host
3. Sign the CSR with the serverAuth and clientAuth flags
4. Import the CA in your profiles and trust that CA (vpn -> profiles, about -> trust)

Still broken in iOS 18.0 beta 6 (22A5338b)!

This regression ought to be fixed as it was in 17.0.

I appreciate that there may be a workaround, but my mail server is remote and I think it's unacceptable to require disturbing a longstanding mail server configuration (there is high risk of breakage) in order to make this work. Especially when macOS does the right thing. iOS should be consistent.

I agree but I needed it to work now and am only sharing a workaround for the sake of everybody hitting this issue until it’s fixed .

Sadly, this regression has shipped in iOS 18.0 (22A3354). I am not optimistic that we will see a fix going forward.

The unfortunate reality of the way things work in Apple software engineering is that problems get deprioritized into oblivion unless users are clamoring for a fix. Regressions are prioritized, but once a regression has shipped and (almost) nobody complains, then the chances of it ever being fixed are greatly reduced, especially if there is a workaround, however cumbersome it is. With the exception of security issues, Engineering’s focus is primarily on new hardware support, “tentpole” features, and high-profile regressions resulting from changes driven be those things. It seems like there are never enough engineers to fix low-priority longstanding issues.

I had really hoped to see more feedback from others on this regression, but I guess it must be a minority configuration.

I really do not look forward to disturbing my longstanding mail server configuration, which will risk breaking e-mail on my Mac, the only way I can access my e-mail at this point. As I’m away from home until the end of the month, I won’t risk messing with it until then.

I have the same problem. iOS devices are screwed, but I can "trust" away on my Macs. I tried the workaround but I'm not good enough with certs to get it to work apparently. For now I am using a 3rd-party email client, but it's not ideal. I would rather go back to Mail. Apple, please fix this. My symptoms are that I can "verify" the account after "trusting" the cert, and the initial download of my mailbox works fine. But after the initial load, all other connects fail with the "bad certificate" -9808.