GNOME Bugzilla – Bug 735191
[IMAPx] Avoid storing server-disallowed message flags
Last modified: 2014-10-21 13:04:00 UTC
Created attachment 284145 [details] output of CAMEL_DEBUG=imapx:io So I have to use an email account at the university here, which runs Exchange but allows IMAP access. The problem is that I frequently hit a situation where I reopen Evolution from another computer (both computers have 3.12, but this problem existed with 3.10 too) and then see that it cannot sync the changes for some odd reason. I get a big error infobar that says this: Failed to refresh folder 'ETS: Sent Items': Error syncing changes: Command Argument Error. 11 Note that in this case it's failing to sync the "Sent Items" folder, but sometimes the Inbox is the one that fails to sync. I've not figured out what exactly causes this and when, given that my two computers have their accounts configured identically (with "Quick Resync" disabled in Evolution's IMAP prefs); at the moment, one of them has no syncing issues and the other has syncing issues, but it could easily be the other way around. This seems not to be a completely isolated problem, as I can see from: - https://mail.gnome.org/archives/evolution-list/2014-June/msg00095.html - bug #512075 - the million search results for exchange 2010 imap error 11 attaching the output of CAMEL_DEBUG=imapx:io
Actually, my memory is fuzzy so I'm not 100% sure it happens with the INBOX folder too, maybe it's just the "Sent Items" folder. Indeed, in the preferences for the account, I have told evolution that the remote folder "Sent Items" (ETS/Sent Items) is the one to consider for the Sent Items folder. Maybe that's the problem.
A Google search suggests this is an Exchange server bug. http://serverfault.com/questions/312321/exchange-2010-imap-issue Probably NOTGNOME.
*** Bug 730652 has been marked as a duplicate of this bug. ***
Ok, definitely not just the "Sent items" folder, it has started occuring for my Inbox folder again today, and it's extremely annoying. Any further info I can provide now that it's occuring on that computer too? It occurred after I tried deleting a selection of multiple mails and switching to another folder quickly, I think. For what it's worth, Geary* seems to be (so far) unaffected by this problem, and unfortunately we have to be able to interface with mail servers "out there in the world" in academia or enterprise circles to be considered seriously. *: AFAIU, Geary is a standalone IMAP implementation, not using EDS.
My Exchange 2010 exposes these CAPABILITY-ies only: > H00052 CAPABILITY > * CAPABILITY IMAP4 IMAP4rev1 AUTH=NTLM AUTH=GSSAPI AUTH=PLAIN UIDPLUS CHILDREN IDLE NAMESPACE LITERAL+ > H00052 OK CAPABILITY completed.' though more importantly the SELECT folder response looks like this: > H00052 SELECT INBOX' > * 110 EXISTS > * 0 RECENT > * FLAGS (\Seen \Answered \Flagged \Deleted \Draft $MDNSent) > * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \Deleted \Draft $MDNSent)] Permanent flags > * OK [UNSEEN 57] Is the first unseen message > * OK [UIDVALIDITY 83] UIDVALIDITY value > * OK [UIDNEXT 492] The next unique identifier value > H00052 OK [READ-WRITE] SELECT completed. while the focus is on the PERMANENTFLAGS response line. A Google servers returns something like this: > * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)] Flags permitted. I skipped a list of set flags in the response, because the most important is the "\*" tag, which means that the client can store custom flags (other than those listed) on messages in that folder. Clearly, Exchange server doesn't allow it, thus I can reproduce the error "Error syncing changes: Command Argument Error. 11" when I change seen flag on a meeting-related message. The same as in your log, this invokes this store command: > F00069 UID STORE 1,855 +FLAGS.SILENT ($has_cal) while the $has_cal flag is not part of the PERMANENTFLAGS. That means that imapx is storing forbidden flags. I swear this used to work properly, both in IMAPx and the old good IMAP providers.
Created commit bf3aed4 in eds master (3.13.6+) [1] Created commit 513af2a in eds evolution-data-server-3-12 (3.12.6+) [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=bf3aed4
*** Bug 621837 has been marked as a duplicate of this bug. ***
I caused a regression with these changes, as reported at bug #738724.