Bug encounterd with IMAP server hosted by OVH (appears to be a dovecot instance (I can't figure the version). The scenario I can reproduce is the following: - Launch Trojita for the first time (not configured) - Entering my connection settings - Connection is fine, I accept the SSL certificate - The INBOX appears in the left panel with the right number of unread messages. - I click on the INBOX folder, the list of messages appears correctly - I select a message, the content is displayed correctly. - I select another folder then, everything seems ok, - I select INBOX again -> QRESYNC error The complete output: 1 >>> "y1 ID (\"name\" \"Trojita\" \"os\" \"Qt/5.5.1; xcb; Linux; Ubuntu 16.04.2 LTS\" \"version\" \"v0.7-260-ge745755-dirty\")" 1 >>> "y2 ENABLE QRESYNC" 1 >>> "y3 LIST \"\" \"%\" RETURN (SUBSCRIBED CHILDREN STATUS (MESSAGES UNSEEN RECENT))" 1 >>> "y4 SELECT INBOX (CONDSTORE)" 1 >>> "y5 UID SEARCH RETURN (ALL) ALL" 1 >>> "y6 FETCH 1:2818 (FLAGS)" 1 >>> "y7 UID FETCH 17,5841,5845:5848,5850:5856,5858:5865,5867:5880,5883:5906,5908:5910 (ENVELOPE INTERNALDATE BODYSTRUCTURE RFC822.SIZE BODY.PEEK[HEADER.FIELDS (References List-Post)])" 1 >>> "y8 IDLE" 1 >>> "DONE" 1 >>> "y9 UID FETCH 5899 (BODY.PEEK[1])" 1 >>> "y10 LIST \"\" \"INBOX.%\" RETURN (SUBSCRIBED CHILDREN STATUS (MESSAGES UNSEEN RECENT))" 1 >>> "y11 UID FETCH 5906 (BODY.PEEK[1.2])" 1 >>> "y12 UID FETCH 5902 (BODY.PEEK[1] BODY.PEEK[2])" 1 >>> "y13 IDLE" 1 >>> "DONE" 1 >>> "y14 SELECT \"INBOX.Archives\" (CONDSTORE)" 1 >>> "y15 IDLE" 1 >>> "DONE" 1 >>> "y16 SELECT INBOX (QRESYNC (1412601342 12776 (1410,2115,2468,2644,2732,2776,2798,2809,2815,2818 4220,5092,5509,5709,5805,5864,5889,5900,5906,5910)))" "y16 BAD Error in IMAP command SELECT: Invalid QRESYNC parameters" I tested the same SELECT command manually (through openssl s_client command) and got the same error. But I also tested the command with this form: SELECT INBOX (QRESYNC (1412601342 12776 4220,5092,5509,5709,5805,5864,5889,5900,5906,5910)) and got some better result at first sight: 06 SELECT INBOX (QRESYNC (1412601342 12776 4220,5092,5509,5709,5805,5864,5889,5900,5906,5910)) * OK [CLOSED] Previous mailbox closed. * FLAGS (\Answered \Flagged \Deleted \Seen \Draft Junk NonJunk $Forwarded $MDNSent) * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft Junk NonJunk $Forwarded $MDNSent \*)] Flags permitted. * 2818 EXISTS * 0 RECENT * OK [UNSEEN 1649] First unseen. * OK [UIDVALIDITY 1412601342] UIDs valid * OK [UIDNEXT 5911] Predicted next UID * OK [HIGHESTMODSEQ 12776] Highest 06 OK [READ-WRITE] Select completed. It seems the dovecot server doesn't accept the last parenthesized list if no known UIDs sequence is provided, so this won't work: SELECT INBOX (QRESYNC (1412601342 12776 (1410,2115,2468,2644,2732,2776,2798,2809,2815,2818 4220,5092,5509,5709,5805,5864,5889,5900,5906,5910))) But this will work: SELECT INBOX (QRESYNC (1412601342 12776 1:5910 (1410,2115,2468,2644,2732,2776,2798,2809,2815,2818 4220,5092,5509,5709,5805,5864,5889,5900,5906,5910))) Where 5910 = UIDNEXT - 1 Section 3.2.5.1 of the RFC 7162 states that: "If the list of known UIDs was also provided, the server should only report flag changes and expunges for the specified messages. If the client did not provide the list of UIDs, the server acts as if the client has specified "1:<maxuid>", where <maxuid> is the mailbox's UIDNEXT value minus 1. If the mailbox is empty and never had any messages in it, then lack of the list of UIDs is interpreted as an empty set of UIDs." It's not very clear what they refer by "the list of UIDs" but I assume it's for the list of known UIDs, am I right?
Created attachment 107094 [details] Proposed patch
(In reply to Matthieu Hazon from comment #1) > Created attachment 107094 [details] > Proposed patch I've added a patch in attachments. This was tested on ovh.net, laposte.net, gandi.net, free.fr IMAP servers.
Hi Matthieu, thanks for going through the trouble of debugging this paroblem and providing a patch. Sorry for a late response, I've been on a month-long holiday recently. I won't merge this patch as-is for a bunch of reasons. First of all, I believe that this issue was reported to the Dovecot upstream and fixed in 2010 [1] in all of their by-then maintained branches. Is there any chance of asking your IMAP service provider to upgrade their Dovecot? I find it a little bit worrying that this fix has not made it through whatever distribution/upgrading channels that they are using. I realize that there's only a small chance of success here, but it never hurts to ask. We do not generally carry fixes for stuff like this which has been fixed upstream for ages. Also, as the rest of the thread at [1] suggests, this might need a range of 1 to (2^32)-1 in order to also catch all UIDs that we haven't seen before (please check the RFC7162 if it's correct). That's one more special case which needs to be unit-tested properly. Right now, I do not think that this is something worth the extra effort, but please do comment if you disagree. As a quick fix, you can add "QRESYNC" to the list of blacklisted IMAP capabilities. This effectively reverts to a CONDSTORE-level functionality which is still better than plain RFC3501-like SELECT. Perhaps we need to add some extra-careful infrastructure which automatically enables quirks like this one in case of buggy servers... [1] https://dovecot.org/list/dovecot/2010-August/052025.html
Hi Jan, Thank you for your answer. No worries for the delay, I was in holidays too :) I agree this really seems to be a server side issue. I will do my best to contact my provider. Thanks for the link though, it will help. I understand your point. At the begining, my point of view was that this patch seemed really transparent for the client as we just "enforce" what the server should already understand. This should change nothing for the working servers and fix the others. But I acknowledge there could be a risk. Especially because I find the RFC unclear when it states: "If the client did not provide the list of UIDs, the server acts as if the client has specified "1:<maxuid>", where <maxuid> is the mailbox's UIDNEXT value minus 1" I assumed the UIDNEXT value is the last one we know but it's not specified there. Plus, the patch I provided seems to do the job but as you said, it can't be proven to be safe without proper testing. Anyway, I'll let you know if I make some progress with my provider to fix the root cause of this issue.
This bug has had its resolution changed, but accidentally has been left in NEEDSINFO status. I am thus closing this bug and setting the status as RESOLVED to reflect the resolution change.