https://bugs.kde.org/show_bug.cgi?id=417756
--- Comment #6 from Jan Kundrát <j...@kde.org> ---
(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.
--
You are receiving this mail because:
You are watching all bug changes.
