GNOME Bugzilla – Bug 339028
Failure to refresh IMAP inbox ("Incomplete server response")
Last modified: 2013-11-11 23:57:32 UTC
Please describe the problem: Whenever Evolution attempts to update my work inbox (Exchange via IMAP) then I get an error dialog and no new mail is found. Steps to reproduce: Attempt to connect to my work inbox. Actual results: This error dialog: Error while Refreshing folder. Incomplete server response: no information provided for message 1 Expected results: I get to read my emails. :) Does this happen every time? Since yesterday afternoon, yes. Other information: Log attached as requested in #evolution I can connect to my inbox on another server (running courier-imap) using Evolution. I can connect to my work inbox using Outlook on a colleague's machine. Old mail in the inbox was still present and readable using Evolution until I moved it away to a local folder while I was trying to figure out what was going on. Other IMAP folders on the same server are still working fine via Evolution. Google finds a similar-sounding problem for someone connecting to dovecot last year. I emailed him to ask if he found a fix and he said moving ~/mail/.imap away did it for him. Moving the whole of ~/.evolution away didn't fix my problem, nor did creating a new Linux user account and running evolution as that user, setting up my work email account and trying to connect from there. Same error dialog.
Created attachment 63865 [details] Log requested in #evolution
Apparently I misunderstood the guy with the dovecot problem, it was ~/mail/.imap on the server end that he moved away. Obviously I don't have any particularly similar options with Exchange. :) I'm assuming that if it's possible for Exchange to get into this state, it might be useful for Evolution to handle it more gracefully even if it is erroneous.
the problem is that if a state like this is reached on the server, it becomes a crap shoot for the client. The first time I had seen this (never seen it before with Exchange, only with Courier), I had sent an email to the author (Mark Crispin) of the IMAP specification asking how the client should deal with that problem and he told me that it's an impossible state to deal with in the client and the only sane thing for the client to do is abort. It becomes impossible (or at the very least extremely difficult and prone to error) for the client to keep its state syncronised with the server. (Remember that IMAP is not single-client - it is meant to be able to be accessed by multiple clients at the same time all manipulating the same set of folders) With an error like: A00052 NO Unrecognized internal error: 0x80040108 I'd be inclined to abort anyway, continuing may risk corrpution of the mailbox or god knows what.
To follow up on this; I managed to get things working again by installing PINE, using that to connect to the inbox, and deleting message #1 - which had no subject, date, to or from address, or message body, as far as I could tell. Outlook would connect and work perfectly but without displaying this message. Mutt failed to connect in much the same way as Evolution. Now that the malformed message is deleted, all clients are working as normal. I don't know if this means there's something to be learned from the way that PINE interprets the INBOX, or whether it means that PINE is taking a horrible risk that just happened to work in my favour on this occasion.
Denny: To clear the cache corresponding to an exchange mailer account, you should have used: rm -rf ~/.evolution/mail/exchange/<account>/<folder> Should this bug remain opened?
From original report: > Moving the whole of ~/.evolution away didn't fix my problem Also, does mail/exchange/* apply to IMAP access to an Exchange server? The bug 'needs more information', I don't know what kind - maybe someone is going to look at how PINE works in the same situation.
Denny: For IMAP access, it is: ~/.evolution/mail/imap/*
I have encountered this problem as well. Using IMAP to an exchange server, i have an inbox with 3892 messages, and syncing yields the error: Incomplete server response: no information provided for message 3893 I have not been able to get any new mail via Evolution since this problem appeared. However, I can access this IMAP account successfully using the MacOSX mail client, and via Thunderbird. Thunderbird does produce an error message: "The current command did not succeed. The mail server responded: The requested message could not be converted to an RFC-822 compatible format.." but Thunderbird is able to fetch new messages despite this. Note also that deleting .evolution/mail/imap/* did not fix the issue. Let me know if i can provide any assistance debugging this problem. Looks like i'm switching to Thunderbird for now, though. -SEan
I've got an Exchange server that does both MAPI and IMAP. If I use IMAP, I get this bug, and this error message. I can't read the Inbox, although I can read any other folder. If I use Mapi, I get identical symptoms, except the error message is "Fetching items failed: OpenMessage: MAPI error (0xfffff9bf) occurred." I can read mailboxes other than Inbox. Other mail clients can read the mailbox fine. If the mailbox is completely empty, I don't get an error message.
"Incomplete server response" still reproducible in 3.0.2. I am forced to use Thunderbird to read this particular folder. Which code is responsible for this error? The correct behavior should be to parse and display the "incomplete" message the best way possible and keep going instead of throwing a fatal error.
(In reply to comment #9) > I've got an Exchange server that does both MAPI and IMAP. > > If I use IMAP, I get this bug, and this error message. I can't read the Inbox, > although I can read any other folder. > > If I use Mapi, I get identical symptoms, except the error message is "Fetching > items failed: OpenMessage: MAPI error (0xfffff9bf) occurred." I can read > mailboxes other than Inbox. > > Other mail clients can read the mailbox fine. > > If the mailbox is completely empty, I don't get an error message. Can you read this folder using Thunderbird IMAP? In my case there is a bad from Evolution point of view message (sequential message number usually reported: "Incomplete server response: no information provided for message NNNN").
The error message "Incomplete server response" only appears in the older and now deprecated IMAP backend. You might have better luck with the newer "IMAP+" backend (as shown in account settings), which we eventually plan to transition everyone to. Without a contributed patch from someone, the deprecated IMAP backend will not receive a fix for this bug. Upstream no longer actively maintains it. If you can still reproduce the issue with the "IMAP+" backend, we'll talk.
(In reply to comment #12) > The error message "Incomplete server response" only appears in the older and > now deprecated IMAP backend. You might have better luck with the newer "IMAP+" > backend (as shown in account settings), which we eventually plan to transition > everyone to. > > Without a contributed patch from someone, the deprecated IMAP backend will not > receive a fix for this bug. Upstream no longer actively maintains it. If you > can still reproduce the issue with the "IMAP+" backend, we'll talk. IMAP+ backend has less features then "older" and "deprecated" IMAP backend. For example on Defaults tab custom Trash and Junk folder settings don't exist. IMAP Headers configuration tab does not exist. I can't use IMAP+ backend because I depend on Defaults tab folder features. Which source files responsible for a "deprecated" IMAP backend?
(In reply to comment #11) > (In reply to comment #9) > > I've got an Exchange server that does both MAPI and IMAP. > > > > If I use IMAP, I get this bug, and this error message. I can't read the Inbox, > > although I can read any other folder. > > > > If I use Mapi, I get identical symptoms, except the error message is "Fetching > > items failed: OpenMessage: MAPI error (0xfffff9bf) occurred." I can read > > mailboxes other than Inbox. > > > > Other mail clients can read the mailbox fine. > > > > If the mailbox is completely empty, I don't get an error message. > > Can you read this folder using Thunderbird IMAP? > In my case there is a bad from Evolution point of view message (sequential > message number usually reported: "Incomplete server response: no information > provided for message NNNN"). I can read it using thunderbird, kmail and owa. All IMAP. I can't read it using Evolution IMAP, MAPI or IMAP+ (different error messages, same gist)
Can someone tell me where in Evolution or libcamel (or whatever) source code to start looking to go: - if message==incomplete then { skip_message; } ?? Either imap, imap+ or mapi. I'll recompile and patch. I'm running on a netbook, though, so a pointer in the right direction would be appreciated.
The following might be a red herring, but it might be relevant. I can reproduce a similar problem in Thunderbird if I try really hard. I can get Thunderbird to get one or more messages that have neither sender, recipient nor subject. In other words: an incomplete message. Here's how to do it: - Use Thunderbird, and use IMAP, and use IMAP IDLE. - At the same time log in using IE OWA - Setup a new server-side filter - When you click commit, Thunderbird gets the empty message. - If you dare delete that empty message, the server-side filter is deleted. Here's how to avoid it: - Use thunderbird - Log out - Log in using IE OWA - Setup server side filters. - Log out IE OWA - Start Thunderbird. No empty messages are listed. I wonder just how Exchange stores server-side filters. Maybe it's a place-holder for the filter.
Imap+ error message: Error syncing changes: Command Argument Error. 11
There seems to be a problem with ParentOf(Inbox) I've made the error non-critical. (continue; instead of break;) I now have valid data in .local/share/evolution/mail/imap/ Nuking them refreshes them. Evolution's Inbox view is empty, but doesn't give an error. So although the mails have been transferred, Inbox still displays as empty. Summary says (0 total) The mailbox has 260 odd messages in it that Evo tries to grab info for. Message numbers 1 and 2 are incomplete. All the other messages have complete data. All the other messages have unique UIDs. There are 98-odd messages marked as undeleted by Exchange. Kmail, OWA, and others agree. Evolution's summary sometimes displays (-98 unread, 0 total); usually displays (0 total) The other 160 are deleted, still on the server. So now I have recent mails in .local/share/evolution/mail/imap/, but nothing in the folder summary. summary->visible_count is correct. camel_folder_summary_save_to_db() never thinks it's dirty. If I force it dirty: (evolution:26695): camel-CRITICAL **: camel_folder_get_parent_store: assertion `CAMEL_IS_FOLDER (folder)' failed
Imapx seems to die here: [imapx:B] token TOKEN 'B00044' [imapx:B] Got completion response for command 00044 'IDLE' [imapx:B] token TOKEN 'OK' [imapx:B] token TOKEN 'IDLE' [imapx:B] ** Starting next command [imapx:B] - we're selected on 'INBOX', current jobs? [imapx:B] -- Checking job queue [imapx:B] -- 10 'STORE'? [imapx:B] --> starting 'STORE' [imapx:B] Starting command (active=1,) B00046 UID STORE 199836:199840 +FLAGS.SILENT (JUNK) [imapx:B] camel_imapx_write: 'B00046 UID STORE 199836:199840 +FLAGS.SILENT (JUNK) ' [imapx:B] camel_imapx_read: buffer is 'B00046 BAD Command Argument Error. 11 ' [imapx:B] token TOKEN 'B00046' [imapx:B] Got completion response for command 00046 'STORE' [imapx:B] token TOKEN 'BAD' [imapx:B] token TOKEN 'Command' [imapx:B] ** Starting next command [imapx:B] starting idle
If I ignore STORE errors, I can read the inbox. But I think I can't mark messages as Junk. What's the easiest way to confirm this on Exchange 2007?
Evo's junk filter saves in INBOX/Junk, but on Exchange, the server-side filters seem to go to "INBOX/Junk E-mail" (note the space in the folder name) Disabled Evo's junk Inbox filtering (on by default)
Created attachment 193311 [details] [review] imapx exchange2007 junk My very ugly patch for IMAPX/IMAP+. Sorry, no IMAP. Note that this will now ignore ALL STORE errors -- possibly including ones we actually want to respond to. The patch is dirty (bad indentation, etc.) It's just here until someone can confirm that this works around the problem, or someone else says how to disable setting the junk flag on Exchange.
This is the wrong answer. The STORE command is *expected* to fail; in the SELECT response the server *told* us that it didn't support arbitrary flags, and we still tried to set one. *That* is the real bug. There is a bug open for it already, I think.
Is that still an issue after all this time?
I no longer have access to the same server to test against.
Closing this bug report as obsolete, then. Please feel free to reopen this bug if you can provide the situation changes and you can reproduce the bug. Thanks!