Problem email client iPhone ios18.2
Hello,
I have a fairly new installation of the Dovecot server version 2.3.19.1 on Debian 12.8.
In general, the server works correctly. It sends and receives emails without issues. The clients primarily use Thunderbird on desktops and Gmail on Android.
However, some clients are using iPhones with various hardware versions. Those with iOS below version 18 work correctly without any issues. Those who have updated their phones to version 18 and now even 18.2 are experiencing problems with mailbox synchronization.
On version 18.2, the issue appears as follows: When you open the app, you can read several messages. They load correctly, but, for instance, attachments do not. If I wait for some time, the attachment eventually loads. During this time, I observe the server logs, and it shows that a certain session on the Dovecot server has ended.
Dec 17 13:13:01 iredmail0 dovecot[408]: imap(xxx@xxx.com)<44785><1QGZCHcp/+3AqM2O>: Disconnected: Connection closed (UID SEARCH finished 92.295 secs ago) in=2972 out=6076956 deleted=0 expunged=0 trashed=0 hdr_count=0 hdr_bytes=0 body_count=36 body_bytes=6059064
Dec 18 08:40:41 iredmail0 dovecot[408]: imap(xxx@xxx.com)<177412>: Disconnected: Connection closed (UID FETCH finished 90.079 secs ago) in=5126 out=1304237 deleted=0 expunged=0 trashed=0 hdr_count=94 hdr_bytes=289688 body_count=89 body_bytes=969615
Dec 18 08:42:19 iredmail0 dovecot[408]: imap(xxx@xxx.com)<177410><D5mqU4cpZ+nAqM2O>: Disconnected: Connection closed (UID FETCH finished 95.051 secs ago) in=4475 out=1162785 deleted=0 expunged=0 trashed=0 hdr_count=95 hdr_bytes=281674 body_count=61 body_bytes=839545
Dec 18 08:44:17 iredmail0 dovecot[408]: imap(edyta.kowalewska@laktopol.com.pl)<177918>: Disconnected: Connection closed (UID FETCH finished 92.132 secs ago) in=29399 out=30266644 deleted=0 expunged=0 trashed=0 hdr_count=565 hdr_bytes=1726228 body_count=628 body_bytes=28109455 After the session is closed, the attachment loads immediately. From the logs and router analysis, it appears that the download happens in another previously opened session.
After this incident, I go to another message with an attachment, and the situation repeats. There are also situations where the email body does not load, and the app waits for the server until the session closes and the content is fetched in another session.
It does not matter whether I connect to the server via the internet or through a local network.
On an iPhone 7 with iOS 15.8.3, everything works smoothly. Attachments open without issues.
On iOS 18.1.1, attachments do not load, and the session does not close on its own. It takes forever unless the app is closed.
In the Gmail app, everything works correctly without any issues.
This is clearly a problem with the mail client on iPhone. However, is there anything I can adjust in my server settings to mitigate this issue for users?
My dovecot configuration https://pastebin.com/UPNQ5dZz
Note: For the record, we are getting similar reports.. Attachment not loading with the latest release of IoS on iPhones..
Unfortunately, it's been hard to replicate so have no answers for you..
On 2024-12-18 03:25, via dovecot wrote:
Hello,
On an iPhone 7 with iOS 15.8.3, everything works smoothly. Attachments open without issues.
On iOS 18.1.1, attachments do not load, and the session does not close on its own. It takes forever unless the app is closed.
In the Gmail app, everything works correctly without any issues.
This is clearly a problem with the mail client on iPhone. However, is there anything I can adjust in my server settings to mitigate this issue for users?
-- "Catch the Magic of Linux..."
Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Reg. TradeMark of Wizard Tower TechnoServices Ltd.
604-682-0300 Beautiful British Columbia, Canada
On Dec 18, 2024, at 3:25 AM, via dovecot <dovecot@dovecot.org> wrote:
I have a fairly new installation of the Dovecot server version 2.3.19.1 on Debian 12.8. [...] On version 18.2, the issue appears as follows: When you open the app, you can read several messages. They load correctly, but, for instance, attachments do not. If I wait for some time, the attachment eventually loads. During this time, I observe the server logs, and it shows that a certain session on the Dovecot server has ended.
As a point of comparison: We're using Debian 12.8 with Dovecot 2.3.21.1 from <https://packages.debian.org/bookworm-backports/dovecot-core>, and we have not had any reports of this. I know plenty of our customers use iOS 18 (as do I).
We did have a report of one customer who could not view _any_ messages on their iPhone after upgrading (their description was that the list view worked properly, including the short previews, but when trying to view individual messages, "it just shows a blank grey background"). But that customer had more than 72,000 messages in their Inbox folder, and archiving the older messages into different folders apparently solved it; I'm not sure if the problem was even related to iOS 18.
Btu anecdotally, you might want to try upgrading to Dovecot 2.3.21.1, and/or making sure that affected customers have a reasonable number of messages in all their folders.
-- Robert L Mathews
Thank you for the answers and suggestions. I am preparing a clone of the machine and will attempt to upgrade Dovecot to the latest version, 2.3.21.1. I will inform you how everything behaves after the Dovecot update.
The users have a lot of mail, but they use yearly archives. Each folder contains a maximum of 5,000-8,000 messages. So, I would rule that out.
-- Andrzej Milewski
Hi, I managed to create a proper clone of the machine for testing from my mail server. I installed the current version 2.3.21.1. Unfortunately, there are no changes. The server behaves exactly the same as it did before the update.
-- Andrzej Milewski
Hi,
Could you show me your Dovecot configuration? My installation is from iRedMail, and I'm worried that I might have something set up that's causing this effect with the new iOS. I would like to compare and see what might be different between a working system.
There's a slight difference between my test environment, where the session is closed, and upon opening a new session, the attachment is loaded. In the production environment, the session isn't closed, but loading the attachment takes about the same time as in the test environment, around 90 seconds. All this happens within the same open session.
The difference between the test machine and the production one lies in the certificates. The test one uses a self-signed certificate, while the production one uses a Let's Encrypt certificate.
I also had one report of what you describe today and was able to reproduce it on two different systems. No cause found yet.
I tried to capture a packet trace using clear text imap, but then the attachment loaded immediately. I will do more tests tomorrow.
Op 18-12-2024 om 12:25 schreef via dovecot:
On version 18.2, the issue appears as follows: When you open the app, you can read several messages. They load correctly, but, for instance, attachments do not. If I wait for some time, the attachment eventually loads. During this time, I observe the server logs, and it shows that a certain session on the Dovecot server has ended.
So I managed to capture the IMAP session on my private setup at home when the attachment didn't load:
========== CUT ===========
- 4296 FETCH (UID 79319 INTERNALDATE "19-Dec-2024 08:45:58 +0100" RFC822.SIZE 4833363 FLAGS (\Recent) BODY[HEADER] {2013} Delivery-date: Thu, 19 Dec 2024 08:45:58 +0100 Received: from company.nl ([2001::]:37117) by l............... A33 OK Fetch completed (0.006 + 0.000 + 0.005 secs). A37 UID FETCH 79319 (UID RFC822.SIZE BODYSTRUCTURE)
- 4296 FETCH (UID 79319 RFC822.SIZE 4833363 BODYSTRUCTURE ((("text" "plain" ("charset" "UTF-8" "format" "flowed") NIL NIL "7bit" 628 20 NIL NIL NIL NIL)("text" "html" ("charset" "UTF-8") NIL NIL "quoted-printable" 14902 273 NIL NIL NIL NIL) "alternative" ("boundary" "------------5EXWg0Iu8dW8o3YRD7dph7JE") NIL NIL NIL)("application" "octet-stream" ("name" "Kersteditie2024.pdf") NIL NIL "base64" 4815062 NIL ("attachment" ("filename" "Kersteditie2024.pdf")) NIL NIL) "mixed" ("boundary" "------------0gFkVYGlMESirTIQU37JNRX9") NIL ("en-US") NIL)) A37 OK Fetch completed (0.001 + 0.000 secs). A38 UID FETCH 79319 (UID BODY.PEEK[1]<0.393216>) A39 UID FETCH 79319 (UID BODY.PEEK[1]<393216.393216>) A40 UID FETCH 79319 (UID BODY.PEEK[1]<786432.393216>) A41 UID FETCH 79319 (UID BODY.PEEK[1]<1179648.393216>) A42 UID FETCH 79319 (UID BODY.PEEK[1]<1572864.393216>) A43 UID FETCH 79319 (UID BODY.PEEK[1]<1966080.393216>) A44 UID FETCH 79319 (UID BODY.PEEK[1]<2359296.393216>) A45 UID FETCH 79319 (UID BODY.PEEK[1]<2752512.393216>) A46 UID FETCH 79319 (UID BODY.PEEK[1]<3145728.393216>) A47 UID FETCH 79319 (UID BODY.PEEK[1]<3538944.393216>)
- 4296 FETCH (UID 79319 BODY[1]<0> {15834} --------------5EXWg0Iu8dW8o3YRD7dph7JE Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit
Geachte lezer,............... --------------5EXWg0Iu8dW8o3YRD7dph7JE Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<!DOCTYPE html> <html> <hea............ --------------5EXWg0Iu8dW8o3YRD7dph7JE-- )
- 4296 FETCH (UID 79319 BODY[1]<393216> {0} )
- 4296 FETCH (UID 79319 BODY[1]<786432> {0} )
- 4296 FETCH (UID 79319 BODY[1]<1179648> {0} ) A38 OK Fetch completed (0.006 + 0.000 + 0.005 secs). A39 OK Fetch completed (0.002 + 0.000 + 0.001 secs). A40 OK Fetch completed (0.001 + 0.000 secs). A41 OK Fetch completed (0.001 + 0.000 secs).
- 4296 FETCH (UID 79319 BODY[1]<1572864> {0} )
- 4296 FETCH (UID 79319 BODY[1]<1966080> {0} )
- 4296 FETCH (UID 79319 BODY[1]<2359296> {0} )
- 4296 FETCH (UID 79319 BODY[1]<2752512> {0} ) A42 OK Fetch completed (0.002 + 0.000 + 0.001 secs). A43 OK Fetch completed (0.002 + 0.000 + 0.001 secs). A44 OK Fetch completed (0.001 + 0.000 secs). A45 OK Fetch completed (0.001 + 0.000 secs).
- 4296 FETCH (UID 79319 BODY[1]<3145728> {0} )
- 4296 FETCH (UID 79319 BODY[1]<3538944> {0} ) A46 OK Fetch completed (0.001 + 0.000 secs). A47 OK Fetch completed (0.001 + 0.000 secs). ========== CUT ===========
I did remove the actual message data from the fragment above. Now when I shutdown the app on my phone and restart it, tapping the message again and then on the attachment, it successfully downloaded the attachment. This is a the fragment of the captured IMAP session without the actual data of the attachment:
========== CUT =========== A36 UID FETCH 79328 (UID RFC822.SIZE BODYSTRUCTURE) A33 OK Idle completed (2.245 + 2.245 + 2.244 secs).
- 4295 FETCH (UID 79328 RFC822.SIZE 4833363 BODYSTRUCTURE ((("text" "plain" ("charset" "UTF-8" "format" "flowed") NIL NIL "7bit" 628 20 NIL NIL NIL NIL)("text" "html" ("charset" "UTF-8") NIL NIL "quoted-printable" 14902 273 NIL NIL NIL NIL) "alternative" ("boundary" "------------5Xw8ldQiQkqLE7H0VdtAAAQM") NIL NIL NIL)("application" "octet-stream" ("name" "Kersteditie2024.pdf") NIL NIL "base64" 4815062 NIL ("attachment" ("filename" "AllichtHoornKersteditie2024.pdf")) NIL NIL) "mixed" ("boundary" "------------o0KKQGwxtQLV6Bq9NgmPHlIh") NIL ("en-US") NIL)) A36 OK Fetch completed (0.005 + 0.000 + 0.004 secs). A37 UID FETCH 79328 (UID BODY.PEEK[2]<0.393216>) A38 UID FETCH 79328 (UID BODY.PEEK[2]<393216.393216>) A39 UID FETCH 79328 (UID BODY.PEEK[2]<786432.393216>) A40 UID FETCH 79328 (UID BODY.PEEK[2]<1179648.393216>) A41 UID FETCH 79328 (UID BODY.PEEK[2]<1572864.393216>) A42 UID FETCH 79328 (UID BODY.PEEK[2]<1966080.393216>) A43 UID FETCH 79328 (UID BODY.PEEK[2]<2359296.393216>) A44 UID FETCH 79328 (UID BODY.PEEK[2]<2752512.393216>) A45 UID FETCH 79328 (UID BODY.PEEK[2]<3145728.393216>) A46 UID FETCH 79328 (UID BODY.PEEK[2]<3538944.393216>)
- 4295 FETCH (UID 79328 BODY[2]<0> {393216} JVBERi0xLjQKJeLjz9MKMSAwIG9iago8PAovQ3JlYXRpb25EYXRlIChEOjIwMjQxMjEzMDcy MTIxKzAxJzAwJykKL0NyZ................. ....eHJlZgozNDcxMDMwCiUlRU9GCg== )
- 4295 FETCH (UID 79328 BODY[2]<5111808> {0} )
- 4295 FETCH (UID 79328 BODY[2]<5505024> {0} ) A49 OK Fetch completed (0.003 + 0.000 + 0.002 secs). A50 OK Fetch completed (0.002 + 0.000 + 0.001 secs). A51 OK Fetch completed (0.001 + 0.000 secs).
- 4295 FETCH (UID 79328 BODY[2]<5898240> {0} ) A52 OK Fetch completed (0.001 + 0.000 secs). ========== CUT ===========
So yes, it must be a client issue, but it only seems to appear on dovecot imap servers. I've tested this on my private setup at home with Dovecot 2.3.19.1 from Debian 12 repository as well as at the company where we use Dovecot-ee 2.3.21-8 from the Open-xchange repository where the same happens.
Regard, Frido
Op 18-12-2024 om 12:25 schreef via dovecot:
This is clearly a problem with the mail client on iPhone.
So yes, it must be a client issue, but it only seems to appear on dovecot imap servers. I've tested this on my private setup at home with Dovecot 2.3.19.1 from Debian 12 repository as well as at the company where we use Dovecot-ee 2.3.21-8 from the Open-xchange repository where the same happens.
How do you know it is specific to dovecot? You have tried also others? I think a lot use this cyrus not?
How do you know it is specific to dovecot? You have tried also others? I think a lot use this cyrus not?
Well, I'm not completely sure. That's why I said that it seems to only appear on Dovecot IMAP servers. I've tested it on my Google account, and Outlook where the problem doesn't exist.
On 19. Dec 2024, at 11.24, frido--- via dovecot <dovecot@dovecot.org> wrote:
So I managed to capture the IMAP session on my private setup at home when the attachment didn't load:
- 4296 FETCH (UID 79319 RFC822.SIZE 4833363 BODYSTRUCTURE ((("text" "plain" ("charset" "UTF-8" "format" "flowed") NIL NIL "7bit" 628 20 NIL NIL NIL NIL)("text" "html" ("charset" "UTF-8") NIL NIL "quoted-printable" 14902 273 NIL NIL NIL NIL) "alternative" ("boundary" "------------5EXWg0Iu8dW8o3YRD7dph7JE") NIL NIL NIL)("application" "octet-stream" ("name" "Kersteditie2024.pdf") NIL NIL "base64" 4815062 NIL ("attachment" ("filename" "Kersteditie2024.pdf")) NIL NIL) "mixed" ("boundary" "------------0gFkVYGlMESirTIQU37JNRX9") NIL ("en-US") NIL)) A37 OK Fetch completed (0.001 + 0.000 secs). A38 UID FETCH 79319 (UID BODY.PEEK[1]<0.393216>) A39 UID FETCH 79319 (UID BODY.PEEK[1]<393216.393216>)
These should be BODY.PEEK[2]. iOS Mail seems somehow confused.
I did remove the actual message data from the fragment above. Now when I shutdown the app on my phone and restart it, tapping the message again and then on the attachment, it successfully downloaded the attachment. This is a the fragment of the captured IMAP session without the actual data of the attachment:
========== CUT ===========
- 4295 FETCH (UID 79328 RFC822.SIZE 4833363 BODYSTRUCTURE ((("text" "plain" ("charset" "UTF-8" "format" "flowed") NIL NIL "7bit" 628 20 NIL NIL NIL NIL)("text" "html" ("charset" "UTF-8") NIL NIL "quoted-printable" 14902 273 NIL NIL NIL NIL) "alternative" ("boundary" "------------5Xw8ldQiQkqLE7H0VdtAAAQM") NIL NIL NIL)("application" "octet-stream" ("name" "Kersteditie2024.pdf") NIL NIL "base64" 4815062 NIL ("attachment" ("filename" "AllichtHoornKersteditie2024.pdf")) NIL NIL) "mixed" ("boundary" "------------o0KKQGwxtQLV6Bq9NgmPHlIh") NIL ("en-US") NIL))
This is a different email entirely. Different IMAP UID, different MIME boundaries, second attachment filename is different. So I guess the sender sent it twice.
A36 OK Fetch completed (0.005 + 0.000 + 0.004 secs). A37 UID FETCH 79328 (UID BODY.PEEK[2]<0.393216>) A38 UID FETCH 79328 (UID BODY.PEEK[2]<393216.393216>)
The MIME structure is similar than in the first mail, and here it's correctly using BODY.PEEK[2].
Anyway, this doesn't seem like the issue is related to IDLE like mentioned elsewhere.
Hi,
On 18.12.24 12:25, via dovecot wrote:
However, some clients are using iPhones with various hardware versions. Those with iOS below version 18 work correctly without any issues. Those who have updated their phones to version 18 and now even 18.2 are experiencing problems with mailbox synchronization.
I can't provide any solution but at least you are not alone:
<https://www.heise.de/news/iOS-18-und-iPadOS-18-Massive-Probleme-mit-E-Mail-Abruf-bei-IMAP-Konten-9952739.html> (older news from 25.09.2024)
<https://www.heise.de/news/iOS-und-iPadOS-18-2-Neue-Berichte-ueber-Probleme-mit-Apple-Mail-10198562.html> (current news from 13.12.2024)
<https://discussions.apple.com/thread/255760058?answerId=260985771022&sortBy=rank#260985771022>
<https://communities.apple.com/de/thread/255892816?sortBy=rank>
-- Regards Andreas Haerter
foundata GmbH Steinhäuserstr. 20 76135 Karlsruhe
Sitz der Gesellschaft: Karlsruhe Registergericht: Amtsgericht Mannheim, HRB 714807 Geschäftsführung: Andreas Haerter USt-IdNr.: DE284122682
Several folks using dovecot (and others) have run into this bug as reported above. Not specific to attachments, but in general, broken syncing of Apple Mail shipped with iOS 18.x.x - everything is fine with Apple Mail shipped with iOS before iOS 18...and macOS Mail Version 16.0 (3826.300.87.4.3) shipped with macOS Sequoia 15.2...
There is discussion with Stalwart IMAP server a fix they pushed on their code. The issue seems to be that new Apple Mail in iOS 18 is using command pipelining and
https://github.com/stalwartlabs/mail-server/issues/765#issuecomment-23629310...
"Starting with iOS 18, Apple Mail began using a technique called "pipelining," where multiple IMAP commands are sent together in a single network packet. Specifically, after the IDLE command is terminated with the DONE command, iOS 18 was immediately sending other commands in the same packet.
Although Stalwart supports command pipelining, it was not prepared to handle this scenario. When it received the DONE command, it stopped processing the rest of the packet and ignored any subsequent commands that followed. This caused Apple Mail to get stuck, as its subsequent requests were not being processed correctly."
I happen to be using an older dovecot that shipped with macOS server a few years back. Version: 2.2.30.2 Now, from what I've read, IMAP supports command PIPELINING per the IETF IMAP spec from a long time ago.... Is it possible, that like Stalwartlabs, that dovecot is ignoring and commands it receives after the "DONE" command, and not reading any new commands following DONE that appear in the same packet? Could someone with deep dovecot experience perhaps dive into this and even, perhaps find out if it is APPLE who broke the IETF spec, or if it is a bug within dovecot??
FWIW, I uncommented the imap_capabilities flag in my conf.d/20-imap.conf file and added everything to that line except IDLE. After removing IDLE from the capabilities flag, mail started to sync to iOS Mail. This is strange. I also noticed what appears to be a very HEAVY use of dovecot by the mail client as it tries to use a new 'categorization' feature of Mail in iOS 18...it seems to read every single mail and try to categorize it --- even when I have chosen NOT to use that 'view' of the mail. I also noticed mail missing from iOS Mail but it appears in Mail on macOS 15.2...I was looking at how far back I could scroll both mails and many are missing from iOS....older mail....
Well, I uncommented the imap_capabilities flag and REMOVED the IDLE capability and now iOS 18 Mail client is getting and syncing emails. I suspect the folks over at Stalwart were on to something .... I just don't know why command pipelining had to be added by Apple for the important IDLE feature.
Well, I uncommented the imap_capabilities flag and REMOVED the IDLE capability and now iOS 18 Mail client is getting and syncing emails. I suspect the folks over at Stalwart were on to something .... I just don't know why command pipelining had to be added by Apple for the important IDLE feature.
I don't really understand what you mean, is idle enabled by default? My config has
imap_capability = +SPECIAL-USE
If you connect to imap with netcat assuming telnet isn’t an option it will tell you what your server supports
nc server 143
Your setting says defaults +SPECIAL-USE The + adds to whatever is there already.
On Jan 5, 2025, at 04:50, Marc <Marc@f1-outsourcing.eu> wrote:
Well, I uncommented the imap_capabilities flag and REMOVED the IDLE capability and now iOS 18 Mail client is getting and syncing emails. I suspect the folks over at Stalwart were on to something .... I just don't know why command pipelining had to be added by Apple for the important IDLE feature.
I don't really understand what you mean, is idle enabled by default? My config has
imap_capability = +SPECIAL-USE
So what seems the be the consensus on what the issue is ?
What does the Stalwart patch do exactly - do you have a link for it ?
Scott
On Sunday, 05/01/2025 at 17:13 David Ferrero via dovecot wrote:
If you connect to imap with netcat assuming telnet isn’t an option it will tell you what your server supports
nc server 143
Your setting says defaults +SPECIAL-USE The + adds to whatever is there already.
On Jan 5, 2025, at 04:50, Marc wrote:
Well, I uncommented the imap_capabilities flag and REMOVED the IDLE capability and now iOS 18 Mail client is getting and syncing
emails. I
suspect the folks over at Stalwart were on to something .... I just don't know why command pipelining had to be added by Apple for the important IDLE feature.
I don't really understand what you mean, is idle enabled by default? My config has
imap_capability = +SPECIAL-USE
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
On Mon, 06 Jan 2025 08:36:45 +0100, "Scott Q. via dovecot" <dovecot@dovecot.org> wrote:
So what seems the be the consensus on what the issue is ?
What does the Stalwart patch do exactly - do you have a link for it ?
Are you looking for
<https://github.com/stalwartlabs/mail-server/commit/51c8f7b2796892bb3e365e725ccde9ad89b6103f>
?
On 05/01/2025 11:12 EET david.ferrero--- via dovecot <dovecot@dovecot.org> wrote: Well, I uncommented the imap_capabilities flag and REMOVED the IDLE capability and now iOS 18 Mail client is getting and syncing emails. I suspect the folks over at Stalwart were on to something .... I just don't know why command pipelining had to be added by Apple for the important IDLE feature. _______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org Interesting. Command pipelining should work with IDLE too, but have to check this Aki
On 5. Jan 2025, at 13.57, Aki Tuomi via dovecot <dovecot@dovecot.org> wrote:
On 05/01/2025 11:12 EET david.ferrero--- via dovecot <dovecot@dovecot.org> wrote: Well, I uncommented the imap_capabilities flag and REMOVED the IDLE capability and now iOS 18 Mail client is getting and syncing emails. I suspect the folks over at Stalwart were on to something .... I just don't know why command pipelining had to be added by Apple for the important IDLE feature. _______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.orgInteresting. Command pipelining should work with IDLE too, but have to check this
I'm not aware of any issues with pipelining and IDLE. It should work with and without hibernation. Some quick tests show that it is working. I guess it's possible that there is some way for it to break, but if so we'd need to see some IMAP traffic logs showing something going wrong (pcap ideally).
Looks like I'm still running iOS 18.1.1 on my phone. I guess I could try to upgrade next week and see if it breaks everything with me also.
I’m unfamiliar with how to capture session level client server data being sent over the encrypted port 993.
I’m willing to try if you give me some command line ideas.
Charles Proxy on my iPhone was my main hope but that seems to be focused on HTTPS.
On Jan 10, 2025, at 07:58, Timo Sirainen via dovecot <dovecot@dovecot.org> wrote:
On 5. Jan 2025, at 13.57, Aki Tuomi via dovecot <dovecot@dovecot.org> wrote:
On 05/01/2025 11:12 EET david.ferrero--- via dovecot <dovecot@dovecot.org> wrote:
Well, I uncommented the imap_capabilities flag and REMOVED the IDLE capability and now iOS 18 Mail client is getting and syncing emails. I suspect the folks over at Stalwart were on to something .... I just don't know why command pipelining had to be added by Apple for the important IDLE feature.
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
Interesting. Command pipelining should work with IDLE too, but have to check this
I'm not aware of any issues with pipelining and IDLE. It should work with and without hibernation. Some quick tests show that it is working. I guess it's possible that there is some way for it to break, but if so we'd need to see some IMAP traffic logs showing something going wrong (pcap ideally).
Looks like I'm still running iOS 18.1.1 on my phone. I guess I could try to upgrade next week and see if it breaks everything with me also.
Hello, Today I noticed a new iOS update to version 18.2.1. However, the update doesn't change anything; the same issues persist. Basically, it's not just about the attachments, but that's where it is most noticeable. Overall, the account synchronization isn't working.
-- Andrzej
Hello,
via dovecot wrote on 07.01.25 at 09:48:
Today I noticed a new iOS update to version 18.2.1. However, the update doesn't change anything; the same issues persist. Basically, it's not just about the attachments, but that's where it is most noticeable. Overall, the account synchronization isn't working.
same problem here since iOS 18. What sometimes seems to help is to force-kill the Mail app and restart it, until the process gets stuck again.
IPv4/IPv6 do not seem to make any difference, neither does port 143 or 993.
I'm on 2.3.21.1 on FreeBSD.
Florian
I think there are/were multiple issues, which confuses diagnosis. As a workaround I had disabled imap-IDLE on my (Dovecot) mail server and my iOS 18.2 iPhone was able to get mail, but was still hanging at times.
After updating to iOS 18.2.1, I re-enabled imap-IDLE and mail seems to be working normally. It uses imap-IDLE (near-realtime delivery) when the mail app is open and fetches every 15 minutes otherwise. It gets the mail messages and alerts correctly.
Have you guys tried using XAPPLEPUSHSERVICE ?
I have that enabled and it doesn't even use IDLE.
Scott
On Tuesday, 07/01/2025 at 08:52 dovecot--- via dovecot wrote:
I think there are/were multiple issues, which confuses diagnosis. As a workaround I had disabled imap-IDLE on my (Dovecot) mail server and my iOS 18.2 iPhone was able to get mail, but was still hanging at times.
After updating to iOS 18.2.1, I re-enabled imap-IDLE and mail seems to be working normally. It uses imap-IDLE (near-realtime delivery) when the mail app is open and fetches every 15 minutes otherwise. It gets the mail messages and alerts correctly.
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
I have both IDLE and the XAPPLEPUSHSERVICE but removed IDLE to get ios mail to work at all. It is slower than with IDLE present but acceptable. I will try adding IDLE back after 18.2.1
As I understand from Stalwart server patch, Apple starter command pipelining and many imap servers were not expecting new commands immediately after CLOSE was sent to end IDLE, in the same packet.
On Jan 7, 2025, at 07:42, Scott Q. via dovecot <dovecot@dovecot.org> wrote:
Have you guys tried using XAPPLEPUSHSERVICE ?
I have that enabled and it doesn't even use IDLE.
Scott
On Tuesday, 07/01/2025 at 08:52 dovecot--- via dovecot wrote:
I think there are/were multiple issues, which confuses diagnosis. As a workaround I had disabled imap-IDLE on my (Dovecot) mail server and my iOS 18.2 iPhone was able to get mail, but was still hanging at times.
After updating to iOS 18.2.1, I re-enabled imap-IDLE and mail seems to be working normally. It uses imap-IDLE (near-realtime delivery) when the mail app is open and fetches every 15 minutes otherwise. It gets the mail messages and alerts correctly.
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
Hello everyone,
I am currently running dovecot 2.3.21 on two servers (running behind a haproxy in active/backup) that use replicator syncing between both. One of these is a macOS MacPorts version that has APNS and is my active server. The other one is a backup server, which is a docker image on Ubuntu.
I ran into not being able to update my APNS certificate using an old Mac OS X High Sierra Server, which I have been doing once year or so and then adding it to my dovecot instance (MacPorts on macOS)
After investigating this over the last month, these are my conclusions: Using XAPPLEPUSHSERVICE from dovecot is dead. It might still have worked last August (I saw on a github repo in an issue thread), but Apple closed the services that was using this, so even if I would be able to renew my certificate, I still would not be able to send the push notifications IDLE is the way to go, but iOS 18 has versions where this doesn't work and no mail is delivered at all. dovecot 2.4 no longer supports syncing between two instances using replicator, going forward I need to set up a clustered NFS across my macOS and Ubuntu machines. Until then I need to stay on 2.3.x.
Is this a correct summary? If it is, I will have to remove APNS from my setup and ask my users to move from Push to Fetch.
Yours,
Gerben Wierda (LinkedIn <https://www.linkedin.com/in/gerbenwierda>, Mastodon <https://newsie.social/@gctwnl>, Bluesky <https://bsky.app/profile/gerbenwierda.bsky.social>) R&A IT Strategy <https://ea.rna.nl/> (main site) Book: Chess and the Art of Enterprise Architecture <https://ea.rna.nl/the-book/> Book: Mastering ArchiMate <https://ea.rna.nl/mastering-archimate-edition-3-2/> YouTube Channel <http://www.youtube.com/@GerbenWierda>
On 7 Jan 2025, at 17:40, David Ferrero via dovecot <dovecot@dovecot.org> wrote:
I have both IDLE and the XAPPLEPUSHSERVICE but removed IDLE to get ios mail to work at all. It is slower than with IDLE present but acceptable. I will try adding IDLE back after 18.2.1
As I understand from Stalwart server patch, Apple starter command pipelining and many imap servers were not expecting new commands immediately after CLOSE was sent to end IDLE, in the same packet.
On Jan 7, 2025, at 07:42, Scott Q. via dovecot <dovecot@dovecot.org> wrote:
Have you guys tried using XAPPLEPUSHSERVICE ?
I have that enabled and it doesn't even use IDLE.
Scott
On Tuesday, 07/01/2025 at 08:52 dovecot--- via dovecot wrote:
I think there are/were multiple issues, which confuses diagnosis. As a workaround I had disabled imap-IDLE on my (Dovecot) mail server and my iOS 18.2 iPhone was able to get mail, but was still hanging at times.
After updating to iOS 18.2.1, I re-enabled imap-IDLE and mail seems to be working normally. It uses imap-IDLE (near-realtime delivery) when the mail app is open and fetches every 15 minutes otherwise. It gets the mail messages and alerts correctly.
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
Am 7. Januar 2025 um 15:39 schrieb "Scott Q. via dovecot" <dovecot@dovecot.org mailto:dovecot@dovecot.org?to=%22Scott%20Q.%20via%20dovecot%22%20%3Cdovecot%40dovecot.org%3E >:
Have you guys tried using XAPPLEPUSHSERVICE ?
This seems to be only available when you have an apple developer account?
Apple developer account not required…but for sure an Apple Push Notification account…and probably a mac… I am not 100%. macOS Server had the facilities to get a push certificate and use it with IMAP.
On Jan 8, 2025, at 08:27, Schulz via dovecot <dovecot@dovecot.org> wrote:
Am 7. Januar 2025 um 15:39 schrieb "Scott Q. via dovecot" <dovecot@dovecot.org mailto:dovecot@dovecot.org?to=%22Scott%20Q.%20via%20dovecot%22%20%3Cdovecot%40dovecot.org%3E >:
Have you guys tried using XAPPLEPUSHSERVICE ?
This seems to be only available when you have an apple developer account?
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
Details: https://github.com/st3fan/dovecot-xaps-daemon https://github.com/st3fan/dovecot-xaps-plugin
On 8 Jan 2025, at 18:52, David Ferrero via dovecot <dovecot@dovecot.org> wrote:
Apple developer account not required…but for sure an Apple Push Notification account…and probably a mac… I am not 100%. macOS Server had the facilities to get a push certificate and use it with IMAP.
On Jan 8, 2025, at 08:27, Schulz via dovecot <dovecot@dovecot.org> wrote:
Am 7. Januar 2025 um 15:39 schrieb "Scott Q. via dovecot" <dovecot@dovecot.org mailto:dovecot@dovecot.org?to=%22Scott%20Q.%20via%20dovecot%22%20%3Cdovecot%40dovecot.org%3E >:
Have you guys tried using XAPPLEPUSHSERVICE ?
This seems to be only available when you have an apple developer account?
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
I can confirm iOS 18.2.1 has no included IMAP IDLE fix. To verify this assertion I did:
- quit iOS Mail app AND shutdown my iPhone.
- updated and commented out the imap_capability flag on my dovecot server: conf.d/20-imap.conf (commenting it out means the defaults (including IDLE) will be supported).
Override the IMAP CAPABILITY response. If the value begins with '+',
# add the given capabilities on top of the defaults (e.g. +XFOO XBAR). #imap_capability =IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS XAPPLEPUSHSERVICE ...
reloaded dovecot sudo doveadm reload
powered up iPhone and launch Mail app. I observed NO emails would appear.....NONE....
To verify this is the culprit, I reversed the steps above and immediately could see my Inbox populated.
Has anyone filed a bug at https://feedbackassistant.apple.com ? Could you share the bug number?
Apple prioritizes partially based on how many duplicate reports it receives. So ideally we would all file reports there to increase the priority. It's also often helpful to state the bug number, if known, in your report.
Sean
On 9 Jan 2025, at 13:13, david.ferrero--- via dovecot wrote:
I can confirm iOS 18.2.1 has no included IMAP IDLE fix. To verify this assertion I did:
- quit iOS Mail app AND shutdown my iPhone.
- updated and commented out the imap_capability flag on my dovecot server: conf.d/20-imap.conf (commenting it out means the defaults (including IDLE) will be supported).
Override the IMAP CAPABILITY response. If the value begins with '+',
# add the given capabilities on top of the defaults (e.g. +XFOO XBAR). #imap_capability =IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS XAPPLEPUSHSERVICE ...
reloaded dovecot sudo doveadm reload
powered up iPhone and launch Mail app. I observed NO emails would appear.....NONE....
To verify this is the culprit, I reversed the steps above and immediately could see my Inbox populated.
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
Has anybody else noticed improvements with iOS/iPadOS version 18.2.1 ? I installed the update today, and it looks like Apple Mail and Dovecot are playing nicer together. Unfortunately Apple only mentions "important bug fixes" without any specifics, rendering their 18.2.1 release notes very unhelpful.
-Ralph
No improvement here. I can still reproduce it on iOS 18.2.1
On 10-01-2025 16:49, Ralph Seichter via dovecot wrote:
Has anybody else noticed improvements with iOS/iPadOS version 18.2.1 ? I installed the update today, and it looks like Apple Mail and Dovecot are playing nicer together. Unfortunately Apple only mentions "important bug fixes" without any specifics, rendering their 18.2.1 release notes very unhelpful.
-Ralph
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
I filed this at bugreport.apple.com <http://bugreport.apple.com/> which reroutes to that link below…
Dec 15, 2024 "IMAP sync is broken since upgrading to iOS 18" FB16106553
I also opened up two different cases with Apple Support, after months of no action.
On Jan 10, 2025, at 07:22, Sean McBride <sean@rogue-research.com> wrote:
Has anyone filed a bug at https://feedbackassistant.apple.com <https://feedbackassistant.apple.com/> ? Could you share the bug number?
Apple prioritizes partially based on how many duplicate reports it receives. So ideally we would all file reports there to increase the priority. It's also often helpful to state the bug number, if known, in your report.
Sean
On 9 Jan 2025, at 13:13, david.ferrero--- via dovecot wrote:
I can confirm iOS 18.2.1 has no included IMAP IDLE fix. To verify this assertion I did:
quit iOS Mail app AND shutdown my iPhone. updated and commented out the imap_capability flag on my dovecot server: conf.d/20-imap.conf (commenting it out means the defaults (including IDLE) will be supported). Override the IMAP CAPABILITY response. If the value begins with '+',
add the given capabilities on top of the defaults (e.g. +XFOO XBAR).
#imap_capability =IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS XAPPLEPUSHSERVICE ...
reloaded dovecot sudo doveadm reload
powered up iPhone and launch Mail app. I observed NO emails would appear.....NONE....
To verify this is the culprit, I reversed the steps above and immediately could see my Inbox populated.
dovecot mailing list -- dovecot@dovecot.org <mailto:dovecot@dovecot.org> To unsubscribe send an email to dovecot-leave@dovecot.org <mailto:dovecot-leave@dovecot.org>
funny - i also talked to apple business support and have a case since my FB15701211 never went anywhere. they took a day or so and talked to engineers and stated that there were no other official apple support requests for this issue - which i have to believe means no large org they care about has this issue - or uses dovecot. My Apple Support Case was/is: 102513275820 which can be used as reference if you want to try -
otherwise i am exploring alternatives to dovecot now.
removing IDLE capability is getting us by for now.
On 3. Feb 2025, at 16.17, stephen--- via dovecot <dovecot@dovecot.org> wrote:
funny - i also talked to apple business support and have a case since my FB15701211 never went anywhere. they took a day or so and talked to engineers and stated that there were no other official apple support requests for this issue - which i have to believe means no large org they care about has this issue - or uses dovecot. My Apple Support Case was/is: 102513275820 which can be used as reference if you want to try -
otherwise i am exploring alternatives to dovecot now.
removing IDLE capability is getting us by for now.
I haven't noticed any issues on my iPhone so far, and I haven't heard of our customers complaining about this to us either. So difficult to say when/why it happens..
I think to get anywhere forward with this, we'd need to see IMAP rawlogs from a session (or perhaps multiple sessions for the whole user) where this problems happens. Especially if the problem is IDLE-related, I'd want to see things going wrong after IDLE. Of course, this likely means seeing some email contents in there, but those could be replaced with some <removed>.
As for how to do rawlogs: https://doc.dovecot.org/2.3/settings/core/#core_setting-rawlog_dir
And better not to have imap-hibernation enabled, since that could confuse debugging.
in my experience the only users who complained were mail abusers - with tens of thousands of messages in each folder - tons of folders etc etc. smaller mailboxes seemed fine. i think apple uses some threshold where this new pipelining takes place on larger mailboxes maybe.
there is a lot of info including raw logs here where they ended up patching it in another mail server: https://github.com/stalwartlabs/mail-server/issues/765
On 4. Feb 2025, at 3.53, stephen--- via dovecot <dovecot@dovecot.org> wrote:
in my experience the only users who complained were mail abusers - with tens of thousands of messages in each folder - tons of folders etc etc. smaller mailboxes seemed fine. i think apple uses some threshold where this new pipelining takes place on larger mailboxes maybe.
there is a lot of info including raw logs here where they ended up patching it in another mail server: https://github.com/stalwartlabs/mail-server/issues/765
With Stalwart apparently they had a clear issue with IDLE pipelining. Dovecot is able to handle DONE + commands pipelined just fine, at least in all my tests. So I don't think Stalwart rawlogs are helpful for Dovecot.
Hello,
I experience the same problem (mail headers not loading, mail bodies not loading) since iOS 18 on one of my machines. The other machine seems unaffacted, but I don't know yet which setting is different. The working one is Debian, the broken one FreeBSD.
Terminating the mail app via the task manager and starting again fixes the problem temporarily.
Florian
On 04/02/2025 11:19 EET Florian Effenberger via dovecot <dovecot@dovecot.org> wrote: Hello, I experience the same problem (mail headers not loading, mail bodies not loading) since iOS 18 on one of my machines. The other machine seems unaffacted, but I don't know yet which setting is different. The working one is Debian, the broken one FreeBSD. Terminating the mail app via the task manager and starting again fixes the problem temporarily. Florian _______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org Can you send imap rawlogs privately to me when it's misbehaving? Set rawlog_dir to a world writable directory. Aki
Hi iPhone users
I’m wodering if this problem is solved by now? I have IOS 18.1 and now the 18.3 updated arrived (somehow it skipped 18.2 on my phone). However, I put the update on hold as long as this weird mail issue after updating exists…
Steven
-- https://steven.varco.ch/ https://www.tech-island.com/
Am 04.02.2025 um 10:38 schrieb Aki Tuomi via dovecot <dovecot@dovecot.org>:
On 04/02/2025 11:19 EET Florian Effenberger via dovecot <dovecot@dovecot.org> wrote: Hello, I experience the same problem (mail headers not loading, mail bodies not loading) since iOS 18 on one of my machines. The other machine seems unaffacted, but I don't know yet which setting is different. The working one is Debian, the broken one FreeBSD. Terminating the mail app via the task manager and starting again fixes the problem temporarily. Florian _______________________________________________ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.orgCan you send imap rawlogs privately to me when it's misbehaving?
Set rawlog_dir to a world writable directory.
Aki
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
The problem as described at the start of this thread is not solved in iOS 18.3. A bit more testing shows that it only appears to happen with attachments around 1MB and bigger.
Op 10-02-2025 om 08:18 schreef Steven Varco via dovecot:
Hi iPhone users
I’m wodering if this problem is solved by now? I have IOS 18.1 and now the 18.3 updated arrived (somehow it skipped 18.2 on my phone). However, I put the update on hold as long as this weird mail issue after updating exists…
Steven
Hello,
frido--- via dovecot wrote on 10.02.25 at 14:07:
The problem as described at the start of this thread is not solved in iOS 18.3. A bit more testing shows that it only appears to happen with attachments around 1MB and bigger.
there seem to be two kind of problems, at least on my devices.
Sometimes it takes quite a while to download e-mails per se, with "Connecting..." and "E-mail download..." showing for a longer time. Then, even if that works, some larger mails or attachments cannot be downloaded.
Killing the mail app and starting again temporarily fixes the problem.
I am trying to get a rawlog for Aki, but of course, now that the log is running, the error is not reproducible - Murphy... ;-) I will try to chase it further.
Florian
On 10. Feb 2025, at 15.24, Florian Effenberger via dovecot <dovecot@dovecot.org> wrote:
Hello,
frido--- via dovecot wrote on 10.02.25 at 14:07:
The problem as described at the start of this thread is not solved in iOS 18.3. A bit more testing shows that it only appears to happen with attachments around 1MB and bigger.
there seem to be two kind of problems, at least on my devices.
I'm also wondering if there are multiple issues. I have one way of easily reproducing, but it has nothing to do with IMAP IDLE. Here's a test email which causes the hang - snipped it a bit in the middle which you can fill out yourself with:
dd if=/dev/urandom bs=1024 count=3432 | base64 -w76
If you want to test multiple times, change Message-Id for every delivery. This mail can be simply saved to INBOX, e.g. with doveadm save:
To: <user@example.com> Subject: testing Content-Type: multipart/mixed; boundary="foo" Date: Tue, 17 Dec 2024 06:46:17 +0000 From: <user@example.com> Message-Id: <fooab@example.com>
--foo Content-Type: multipart/alternative; boundary="bar"
--bar Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
asdf --bar--
--foo Content-Description: test.pdf Content-Disposition: attachment; filename="test.pdf" Content-Transfer-Encoding: base64 Content-Type: application/octet-stream; name="test.pdf"
lBjZO0luFuyUiOqQ8KPTTpMyPoNhlSTPPJauDuCVSwbZgaNyhnObul5qrdyPKo0NGiQKA3Kha34A <61642 lines of random> 4cNyk39T2wMsnQavfl8LXwG1vNQylpgmSN4p6fOpmGqQ
--foo--
I have a very similar problem and try to analyse the Issue with Wireshark.
I reporduce it this way - go to an iPhone and try to get the body of an old email - for some iPhones (but not all at the company) recieving the body needs more than a minute - until then, only the "pls wait sign" is on the screen of the iphone. Then suddenly the email content becomes visible.
I downgraded from TLS1.3 to TLS1.2 to be able to decrypt traffic with the priv key from letsencrypt in wireshark. I don't know much about IMAP but it seems that the UID FETCH command is simply executed 1-2 mins AFTER the user tried to receive the Email-Body.
Here a Screenshot with the Time passing in the red rectangle: https://drive.google.com/file/d/1jTajdI6XDTAXNZVUdE1VYLeXi8S6jreA/view?usp=s...
First insight MAYBE that the bug is already fixed - I have two phones which currently doesn't seem to have this problems which have one version number up compared to the ones which have this bug. Their version numbers according to the IMAP Hello (or whatever you call that if you are an IMAP geek):
iPhone with problem: FK2 ID ("name" "com.apple.email.maild" "version" "3826.400.131.2.14" "os" "iOS" "os-version" "18.3.1 (22D72)" "vendor" "Apple Inc")
iPhones without the problem: AK2 ID ("name" "com.apple.email.maild" "version" "3826.400.131.2.15" "os" "iOS" "os-version" "18.3.2 (22D82)" "vendor" "Apple Inc") I2 ID ("name" "com.apple.email.maild" "version" "3826.400.131.2.15" "os" "iOS" "os-version" "18.3.2 (22D82)" "vendor" "Apple Inc")
I will tell the person he should try to update the iOs version and will update you here in case this fixes or doesn't fix it. Thank you!
Hello,
Christian Großegger via dovecot wrote on 26.03.25 at 17:56:
iPhones without the problem: AK2 ID ("name" "com.apple.email.maild" "version" "3826.400.131.2.15" "os" "iOS" "os-version" "18.3.2 (22D82)" "vendor" "Apple Inc") I2 ID ("name" "com.apple.email.maild" "version" "3826.400.131.2.15" "os" "iOS" "os-version" "18.3.2 (22D82)" "vendor" "Apple Inc")
I have that very version installed and still issues that I cannot always reproduce, so it's not a general fix at least.
Florian
I took a deep dive in my wireshark trace and it seems like the Apple Device simply doesn't fullfill the User request in a prioritized way. It seems to follow the IMAP rfc2177 (as by my limited understanding) correctly - but it simply waits for *itself* to mark the IDLE as *Done* (Which can take several minutes or longer) until it even requests the the message which the user requested earlier on the iPhone display. I currently don't think this is a dovecot bug, but I do that only as a hobby and I am not deep into dovecot or imap.
Again the screenshot from before - the red rectangle marks the time the iPhone needed to even start to request the message from the dovecot server. I requested the message via touch press before this time on the iPhone. https://drive.google.com/file/d/1jTajdI6XDTAXNZVUdE1VYLeXi8S6jreA/view?usp=s...
I'm checking to see if everyone else is facing this same issue. In my case, it started with iOS version 18 (or possibly a slightly later update). New messages take an unusually long time to download, and some don't load the content at all. This issue occurs on both my recently acquired iPhone 16e and my older iPhone 6s.
On 27 Mar 2025, at 10:53, Christian Großegger via dovecot <dovecot@dovecot.org> wrote:
Can confirm: iOS 18.3.2 still has this issue :(
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
"Christos" == Christos Chatzaras via dovecot <dovecot@dovecot.org> writes:
I'm checking to see if everyone else is facing this same issue. In my case, it started with iOS version 18 (or possibly a slightly later update). New messages take an unusually long time to download, and some don't load the content at all. This issue occurs on both my recently acquired iPhone 16e and my older iPhone 6s.
I've been seeing wierd problems with iOS 18.x as well. I'm running the Debian 11 version of dovecot. I don't have any traces for anything though. Sometimes it helps to close (swipe up) completely the mail app. But othertimes not. It's mostly apparent when downloading images in emails in my recent experience.
Good news is that it is possible to get debug logs out of an iPhone! I created a debuglog from iPhone where this issue happens and it seems that the answer from dovecot to such a message:
20:27:12 - EX32 UID FETCH 7840 (UID BODY.PEEK[1]...
cannot/is not read by the iPhone. The iPhone tells then in the log that:
20:27:47 - [02-EX] Connection appears to have been stuck for 35.3 s ....
multiple times - until: 20:28:41 - [02-EX] Connection appears to have been stuck for 89.3 s. Cancelling. 20:28:41 - [02] Connection EX failed while 4 command(s) EX33 EX35 EX32 EX34 were running and '<private>' was selected.
And then it opens a new connection, and the previously scheduled message is finally requested.
You can find the logfile here: https://drive.google.com/file/d/1UgUSIVvaGSiEzu5p_gjqyQcucd8XrJvQ/view?usp=s...
And a screenshot of the wireshark trace here: https://drive.google.com/file/d/14lpv36ekMv9LO2tLyzElIE0ApBN8E207/view?usp=s...
participants (24)
-
Aki Tuomi
-
Andreas Haerter
-
andrzej.milewski＠gmail.com
-
Christian Großegger
-
Christos Chatzaras
-
David Ferrero
-
david.ferrero＠zion.com
-
dovecot＠padilla.net
-
Florian Effenberger
-
frido＠0tten.nl
-
Gerben Wierda
-
Herbert J. Skuhra
-
John Stoffel
-
Len Padilla
-
Marc
-
Michael Peddemors
-
Ralph Seichter
-
Robert L Mathews
-
Schulz
-
Scott Q.
-
Sean McBride
-
stephen＠thirdvantage.com
-
Steven Varco
-
Timo Sirainen