Summary: | Invalid QRESYNC parameters when selecting INBOX a second time | ||
---|---|---|---|
Product: | [Applications] trojita | Reporter: | Matthieu Hazon <matthieu> |
Component: | IMAP | Assignee: | Trojita default assignee <trojita-bugs> |
Status: | RESOLVED INTENTIONAL | ||
Severity: | normal | Keywords: | investigated, triaged |
Priority: | NOR | ||
Version: | git | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | Proposed patch |
Description
Matthieu Hazon
2017-08-04 16:52:54 UTC
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. |