I've been suffering crashes of Pegasus Mail when processing messages in IMAP folders provided by some servers, in particular Microsoft's imap-mail.outlook.com. (I'm using port 993 and direct SSL connect.) Most operations work, but anything which involves deleting or moving a message is likely to provoke IMAP error pop-up windows or to crash Pegasus Mail, often after a few more clicks or commands on that mailbox rather than instantly.
I think I have found a difference between an IMAP server without problems and one with them. Here are snippets from some internet session logs saved by Pegasus Mail. (Unless you're David or one of the team trying to modify Pegasus Mail itself, you can stop reading now.)
This led to a crash of Pegasus:
A8 - copy the message to the Deleted folder (worked)
A9 - read the status of the message (worked)
A10 - set the message status to "deleted" (worked)
A11 - read the new current message
This has worked, but there's a response * 3 EXPUNGE which has surprised Pegasus and confused its state.
A12 - before A11's finished, this command starts to read another message
...then it all gets very confused, reading message header and content data and trying to interpret these as IMAP responses.
10:03:29.286: << A8 UID COPY 52289 "Deleted"<cr><lf>
10:03:29.487: >> A8 OK [COPYUID 12 52289 4280] COPY completed.<cr><lf>
10:03:29.494: << A9 UID FETCH 52289 FLAGS<cr><lf>
10:03:29.620: >> * 3 FETCH (FLAGS () UID 52289)<cr><lf>
10:03:29.773: >> A9 OK FETCH completed.<cr><lf>
10:03:29.774: << A10 STORE 3 +FLAGS (\Deleted)<cr><lf>
10:03:29.996: >> A10 OK STORE completed.<cr><lf>
10:03:30.038: << A11 UID FETCH 52294 (FLAGS UID RFC822.SIZE BODY.PEEK[])<cr><lf>
10:03:30.181: >> * 6 FETCH (FLAGS (\Seen) UID 52294 RFC822.SIZE 70304 BODY[] {22531}<cr><lf>
10:03:30.183: >> [Read 16368 bytes]
10:03:30.190: >> [Read 6163 bytes]
10:03:30.196: >> )<cr><lf>
10:03:30.196: >> * 3 EXPUNGE<cr><lf>
10:03:34.558: << A12 UID FETCH 52295 (FLAGS UID RFC822.SIZE BODY.PEEK[])<cr><lf>
10:03:34.574: >> * 9 EXISTS<cr><lf>
10:03:34.576: >> A11 OK FETCH completed.<cr><lf>
10:03:57.376: << A13 CLOSE<cr><lf>
10:03:57.379: >> * 6 FETCH (FLAGS (\Seen) UID 52295 RFC822.SIZE 62283 BODY[] {12790}<cr><lf>
10:03:57.380: << A14 LOGOUT<cr><lf>
10:03:57.381: >> Received: from DM6PR14MB2907.namprd14.prod.outlook.com (2603:10b6:5:1a7::10)<cr><lf>
10:03:57.381: >> by CY4PR1401MB1880.namprd14.prod.outlook.com with HTTPS; Mon, 4 Apr 2022<cr><lf>
A similar command using a different mailbox didn't have the * <n> EXPUNGE response and caused Pegasus Mail no problems. Here's the equivalent snippet from the log file, for comparison. The equivalent of A11 in the first log is A7 in this one.
10:41:39.873: << A4 UID COPY 4347 "Trash"<cr><lf>
10:41:40.054: >> A4 OK [COPYUID 1459765642 4347 81] Copy completed (0.153 + 0.000 secs).<cr><lf>
10:41:40.058: << A5 UID FETCH 4347 FLAGS<cr><lf>
10:41:40.080: >> * 311 FETCH (UID 4347 FLAGS ())<cr><lf>
10:41:40.080: >> A5 OK Fetch completed (0.001 + 0.000 secs).<cr><lf>
10:41:40.080: << A6 STORE 311 +FLAGS (\Deleted)<cr><lf>
10:41:40.107: >> * 311 FETCH (FLAGS (\Deleted))<cr><lf>
10:41:40.108: >> A6 OK Store completed (0.001 + 0.000 secs).<cr><lf>
10:41:45.318: << A7 UID FETCH 4348 (FLAGS UID RFC822.SIZE BODY.PEEK[])<cr><lf>
10:41:45.358: >> * 312 FETCH (UID 4348 FLAGS (\Seen) RFC822.SIZE 11155 BODY[] {11155}<cr><lf>
10:41:45.360: >> [Read 11155 bytes]
10:41:45.363: >> )<cr><lf>
10:41:45.364: >> A7 OK Fetch completed (0.017 + 0.000 + 0.016 secs).<cr><lf>
I hope this is some help to fix the problem. As far as I can tell, the response is allowed by the IMAP protocol during a UID FETCH command.
The problem's not new in version 4.80.
.
