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
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>
participants (18)
-
Aki Tuomi
-
Andreas Haerter
-
andrzej.milewski＠gmail.com
-
David Ferrero
-
david.ferrero＠zion.com
-
dovecot＠padilla.net
-
Florian Effenberger
-
frido＠0tten.nl
-
Herbert J. Skuhra
-
Len Padilla
-
Marc
-
Michael Peddemors
-
Ralph Seichter
-
Robert L Mathews
-
Schulz
-
Scott Q.
-
Sean McBride
-
Timo Sirainen