I get the following message when I try to open my Inbox:
MailboxException: Error when synchronizing all messages: server said that there are 586 messages, but UID (E)SEARCH ALL response contains 1672 entries.
Nevertheless, I am able to open other folders, which happen to contain less messages.
Steps to Reproduce:
1. Launch Trojita
2. Open my Inbox
I get the message mentioned above.
It should display the messages in my Inbox.
Nicolas, could you please attach the IMAP protocol log and reopen this bugreport? The log shall pop automatically, if not, it's in IMAP -> Debugging -> Show IMAP Protocol Log. What IMAP server implementation is this?
Created attachment 80353 [details]
IMAP protocol log
Ah, this is bad. The log comes from an ancient version of the UW-IMAP, a server which is not maintained anymore. The server is sending invalid data in violation of the ESEARCH extension, unfortunately. We *might* add a kludge into Trojita which will try to request an old-fashioned SEARCH instead (and blacklist ESEARCH at the same time), but that will take some time (UW-IMAPD is, thankfully, not that popular anymore). In the meanwhile, you can add ESEARCH into IMAP -> Settings -> IMAP -> Blacklisted Extensions.
For a bit more context, this is how I described this problem in my thesis:
At the time of the ESEARCH adoption, the imap-protocol mailing list witnessed
a disagreement on how exactly the sequence-set shall be interpreted. Mark Crispin, the author of the original IMAP protocol (but not of the ESEARCH extension) implemented ESEARCH in a different manner. He chose to take an advantage of the RFC3501-style definition of UID sequences where the RFC mandates that servers shall treat non-existent UIDs given in sequence sets as if they weren’t referenced from the command at all. For example, if the mailbox contained just UIDs 3, 5 and 10, a client using the 3:10 construct has to be interpreted as if it requested sequence-set 3,5,10. Doing so present certain optimization opportunities to the servers, for example when the client already knows the UID mapping and performs a server-side search for messages matching certain criteria and the result set accurately matches an adjacent range
of messages, the server could take advantage of this adjacency a return a sequence-set in the form of 10:150, even though the mailbox contains only a few UIDs from this range . Furthermore, his another point is that the clients already have two other ways of obtaining the UID mapping, either through the UID SEARCH ALL command or via an explicit UID FETCH 1:*. Needless to say, such a reasoning fails to take into account potential bandwidth savings which can be rather substantial on “reasonable” mailboxes. In the end, the authors of the RFC 4731 disagreed with Crispin  .
Thanks! Adding ESEARCH to the blacklisted extensions solved the problem.
Git commit 0dba37f7367ae20d3ed3f87b2a7a6f3e063a00b0 by Jan Kundrát.
Committed on 09/06/2013 at 14:42.
Pushed by jkt into branch 'master'.
IMAP: do not doubly-encode backslashes when sending mailbox names
I've noticed this in an unrelated bugreport (thanks to Nicolas Sirolli
<firstname.lastname@example.org> in bug 320828).
The encodeImapFolderName shall only convert the Unicode data into a proper
modified-utf-7 thing, not escape the backslashes. This escaping is done by the
Parser when queueing commands. Looks like this bug must have been around for
M +1 -1 src/Imap/Parser/3rdparty/rfccodecs.cpp
M +20 -0 tests/tests/test_Imap_Tasks_ListChildMailboxes/test_Imap_Tasks_ListChildMailboxes.cpp
M +4 -1 tests/tests/test_Imap_Tasks_ListChildMailboxes/test_Imap_Tasks_ListChildMailboxes.h
Looks like noone has time for adding the heuristic of "broken ESEARCH response -> retry with just SEARCH". Given that the server in question is not maintained anymore, I'm closing this bug now. Patches are still welcome, it's just that I don't think any of the existing developers is willing to write them.