Created attachment 126086 [details]
screenshot of message

Imap::Mailbox::KeepMailboxOpenTask attached to INBOX Failed: The connection is being killed for unspecified reason

That's an upstream bug in hosted Exchange environments. You might want to open a support ticket with your e-mail service provider. Sometimes, their IMAP server implementation gets confused by our use of IMAP command pipelining, and returns back garbage consisting of a mixture of actual responses and the client's commands.

There isn't much that we could do except for disabling pipelining altogether, and I do not think we should do that. In IMAP, pipelining has been around for ages (it's been always an async protocol), so this is clearly a server bug that should be fixed server-side.

*** Bug 417876 has been marked as a duplicate of this bug. ***

Coming from Bug 417876, are we sure this is happening because of problems on the server side? Microsoft says it supports IMAP [1] and colleagues of mine are using Thunderbird without any problems. Additionally I couldn't find anywhere mentioning that office365 has problems with pipelining. Therefore I have to ask here first, before hitting the Microsoft forums.

[1] https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/pop3-and-imap4/pop3-and-imap4

I only found one article [2] that suggests to only have only one IMAP connection open at any time. Does Trojita open more than one connection? Is this configurable?

[2] https://uit.stanford.edu/service/office365/configure/thunderbird

Finally, are we sure that we are not hitting some of the spec details of the IMAP protocol? For example "commands which break command pipelining must wait for a completion result response" or "STATUS must not be used to check for new messages in the selected mailbox" ?

(In reply to Dimitrios Apostolou from comment #5)
> Coming from Bug 417876, are we sure this is happening because of problems on
> the server side? Microsoft says it supports IMAP [1] and colleagues of mine
> are using Thunderbird without any problems. Additionally I couldn't find
> anywhere mentioning that office365 has problems with pipelining. Therefore I
> have to ask here first, before hitting the Microsoft forums.

That's no surprise. Thunderbird is not using all advanced features of the IMAP protocol. In short, Thunderbird is a "universal e-mail client" which prioritizes similar behavior over various mail transports, including POP3 and IMAP4, while Trojita is an IMAP e-mail client which uses protocol features to operate quickly and offload as much stuff as possible (and safe) to the IMAP server. This trade-off means that for the end user, the experience with using Trojita against a server which "supports IMAP" to a similar extent that Exchange "supports IMAP" will be bad.

> I only found one article [2] that suggests to only have only one IMAP
> connection open at any time. Does Trojita open more than one connection? Is
> this configurable?

We currently only use one IMAP connection. We will be using more in future, and we'll be using this safely in accordance with the IMAP-related RFCs which explain what is always safe, what is never a good idea, and what depends on the "quality of implementation" (my wording) of the IMAP server.

> Finally, are we sure that we are not hitting some of the spec details of the
> IMAP protocol? For example "commands which break command pipelining must
> wait for a completion result response"

Yup, we understand the limitations on what can be pipelined and what cannot be pipelined. STATUS is safe to pipeline in this context.

> or "STATUS must not be used to check
> for new messages in the selected mailbox" ?

Yes. If you investigate the IMAP log, you will see that we never issue a STATUS for a mailbox that we have SELECTed (or EXAMINEd). The reason for this wording in the RFC is that some IMAP clients might want to avoid tracking EXPUNGE and EXISTS untagged messages and rely on STATUS polling. In IMAP, that's an anti-pattern.

Anyway, just check the raw IMAP log when this happens again. You'll see that "sometimes", Exchange takes part of its input socket buffer and sends it back to the client with seemingly no additional processing. Going back to the snippet of the log that you posted, it reads:

y433 STATUS "Deleted Item* STATUS INBOX (MESSAGES 525 UNSEEN 0 RECENT 0)

That just does not make sense. It starts as a tagged response ("y433" is a tag we used for a command), but then there's no OK/NO/BAD, so that's a broken server right there. It looks as if `y433 STATUS "Deleted Item` (note the missing "s" and the trailing quote of the quoted-string) came directly from our output (and therefore Exchange's input), while `* STATUS INBOX (MESSAGES 525 UNSEEN 0 RECENT 0)` looks like a valid server's untagged response.

If you can find an ABNF production from the grammar given in RFC3501 (or 3501 + any extensions) which satisfies this input as a server's response, I'll buy you a beer and fix this in Trojita. Otherwise, I claim that this is a bug somewhere in the IMAP server.

If you're interested in learning more about how we use IMAP and what features we considered important, Trojita's homepage has a link  to my thesis from 2012 where I talk about the protocol.

I posted a question on the Microsoft community website:

https://answers.microsoft.com/en-us/msoffice/forum/msoffice_outlook-mso_other-mso_o365b/server-errors-with-imap-command-pipelining/a2264816-cb5a-4ee0-a8b3-c6c9a7f5f2a5?tm=1593440721174