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 * <n> EXPUNGE response is allowed by the IMAP protocol during a UID FETCH command.

The problem's not new in version 4.80.

Yes, IMAP is a longtime issue and he's been working on the code for PM 5 until being forced (not only) by the OAUTH2 issues to discontinue his work on PM 5. I'll point him to this thread.

Thank you!

I have been copying all messages from my IMAP inbox to my Pegasus Mail local New Mail folder, then using another email client to delete them from the IMAP server. This avoids crashing Pegasus Mail, and I've got used to doing it over the last couple of years, but it's not very efficient.

I shall very much appreciate the improvement when it can be released!

If help is needed for testing, do ask.

Just wanted to say that this issue has been reported to me and I'll look into it as time permits; if possible, I'll try to squeeze a fix into the upcoming release.

A quick check of RFC3501 indicates that an untagged expunge response must not be sent to a bare FETCH command, but can be sent to a UID FETCH command, as you suggest, so I have a pretty good idea where I need to be looking.

Thanks for the report.

Cheers!

-- David --