GNOME Bugzilla – Bug 400841
Evolution 2.9.6 IMAP Headers broken with default settings
Last modified: 2013-09-13 00:52:00 UTC
Since I updated to 2.9.6 evolution did not see new mails anymore on any of my IMAP servers. The issue was : A00007 UID FETCH 19540:* (FLAGS RFC822.SIZE INTERNALDATE BODY.PEEK[HEADER.FIELDS (DATE FROM TO CC SUBJECT REFERENCES IN-REPLY-TO MESSAGE-ID MIME-VERSION CONTENT-TYPE X-MAILING-LIST X-LOOP LIST-ID LIST-POST MAILING-LIST ORIGINATOR X-LIST SENDER RETURN-PATH X-BEENTHERE )]) A00007 BAD Invalid field-name in UID Fetch BODY.PEEK[HEADER.FIELDS I found that there is now a plugin to select headers to fetch. I switched to 'all' and I get my mail again.
Hmm it looks like http://mail.gnome.org/archives/tinymail-devel-list/2006-November/msg00040.html
I am using evolution 2.9.6 and e-d-s 1.9.6.1
This should probably be in evolution, as mail still happens in the client (not in eds, AFAIK)
Ubuntu bug about that: https://launchpad.net/ubuntu/+source/evolution/+bug/81524
I think the faulty code is in evolution-data-server/camel/providers/imap/camel-imap-folder.c (in imap_update_summary) : #define CAMEL_MESSAGE_INFO_HEADERS "DATE FROM TO CC SUBJECT REFERENCES IN-REPLY-TO MESSAGE-ID MIME-VERSION CONTENT-TYPE " #define MAILING_LIST_HEADERS "X-MAILING-LIST X-LOOP LIST-ID LIST-POST MAILING-LIST ORIGINATOR X-LIST SENDER RETURN-PATH X-BEENTHERE " if (store->headers == IMAP_FETCH_ALL_HEADERS) header_spec = g_string_new ("HEADER"); else { header_spec = g_string_new ("HEADER.FIELDS ("); header_spec = g_string_append (header_spec, CAMEL_MESSAGE_INFO_HEADERS); if (store->headers == IMAP_FETCH_MAILING_LIST_HEADERS) header_spec = g_string_append (header_spec, MAILING_LIST_HEADERS); if (store->custom_headers) header_spec = g_string_append (header_spec, store->custom_headers); header_spec = g_string_append (header_spec, " )"); } For custom_headers the code (from evolution-2.9.6/plugins/imap-features/imap-headers.c) is : do { gtk_tree_model_get (model, &iter, 0, &header, -1); str = g_string_append (str, g_strstrip(header)); str = g_string_append (str, " "); } while (gtk_tree_model_iter_next(model, &iter)); As the 3 strings already contain a space at the end, I would just replace " )" with ")".
Actually dropping this space will left one space at the end, and there should be none according to my tests, I'm writing a better patch.
Created attachment 81262 [details] [review] Drop extra spaces when using default or mailing list headers
Created attachment 81263 [details] [review] Move the space from the end to the beginning when using custom headers
The 2 attached patches move the spaces to the beginning of appended strings to avoid having them when the string is not appended. One applies to evolution-data-server for basic and mailing list headers, the other one is for evolution and does the same for custom headers.
(In reply to comment #0) > > I found that there is now a plugin to select headers to fetch. I switched to > 'all' and I get my mail again. Which plugin is this? How did you select it? I opened the Plugin Manager but don't see anything that looks related. Using 2.9.6-0ubuntu1 here. Cheers.
The plugin is called "IMAP Features" and adds a tab called "IMAP Headers" to the preference window of the accounts which are using IMAP.
(In reply to comment #11) > The plugin is called "IMAP Features" and adds a tab called "IMAP Headers" to > the preference window of the accounts which are using IMAP. Indeed!! Yay. Now I can see new mail. Thanks Pascal.
*** Bug 400929 has been marked as a duplicate of this bug. ***
Against which IMAP server are all these tested? I tested against a GroupWise IMAP server and things seems to be working fine. Based on the above comments, I understand that having multiple spaces is the source of the problem. Pascal: Thanks for your patches. However, http://bugzilla.gnome.org/attachment.cgi?id=81262&action=view will not work if an user chooses to download basic + some custom headers. And http://bugzilla.gnome.org/attachment.cgi?id=81263&action=view will not work since it merges all the custom headers without a space seperating them. Patches with the right approach to follow.
Created attachment 81437 [details] [review] Fix (EDS)
Created attachment 81438 [details] [review] Fix (Evo)
(In reply to comment #14) > Against which IMAP server are all these tested? I tested against a GroupWise > IMAP server and things seems to be working fine. On 2 different servers (one is cyrus the other one I don't know) > Based on the above comments, I understand that having multiple spaces is the > source of the problem. > > Pascal: Thanks for your patches. However, > > http://bugzilla.gnome.org/attachment.cgi?id=81262&action=view will not work if > an user chooses to download basic + some custom headers. Why ? The custom header will come with their spaces. > And http://bugzilla.gnome.org/attachment.cgi?id=81263&action=view will not work > since it merges all the custom headers without a space seperating them. Hmm no, it just adds the space before each header instead of adding it after
Can some one test these patches ? My IMAP Server returns proper headers even if there are multiple sucessive spaces are at the end of the HEADERS.
Pascal: Sorry for the noise. I misread the evolution patch as a result, I mistankingly found that the EDS patch may also not work. (inter-dependant). Your patch also addresses the scenario and looks good. My patch (evo.patch) fixes a memory leak in addition to the above problem.
One scenario where the problem could still exist even after the above patches are committed will be : When the user enters clicks Add Headers and starts typing a lot of headers one after another seperated by multiple spaces. I need to look at ways to disable any keys other than alphabets and numbers on a GtkEntry. We should disable not just spaces, but any markup tags or scripts or any character that cannot be part of a Header name.
Yes you are right for the memory leak :) And yes that would be nice to ensure that headers are correct
Pascal: There is one very little issue with your patch. It may not give the desired result if someone has altered the header-preferences using the old version (wihtout any of our patches, a fresh 2.9.6) Users may be forced to delete all headers and re-add them if they want to use it. Can someone test with the above patches (on a server that doesnt accept multiple spaces in request) and update the bug so that I can commit it ?
I had the same problem with my email account in an IMAP Cyrus server. I tested Sankar' patches and now I can fetch new emails without any problem.
I have committed my patches to the HEAD. I have added a g_print statement to print the HEADER string that will be sent to the server. I will keep this bug open until I remove the g_print statement that I have put in. Pascal: Thanks for your patches. I chose my patch as yours might break the behavior if some users have used the released 2.9.6 and configured some headers. Will love to some more patches from you :)
I'm still having a similar problem. CAMEL_VERBOSE_DEBUG gives me this: sending : A00033 SELECT INBOX received: * 1353 EXISTS received: * 0 RECENT received: * OK [UIDVALIDITY 1157468607] UID validity status received: * OK [UIDNEXT 5098] Predicted next UID received: * FLAGS (Junk $Label1 $Label2 $Label3 $Label4 $Label5 $Forwarded NonJunk $MDNSent \Answered \Flagged \Deleted \Draft \Seen) received: * OK [PERMANENTFLAGS (Junk $Label1 $Label2 $Label3 $Label4 $Label5 $Forwarded NonJunk $MDNSent \* \Answered \Flagged \Deleted \Draft \Seen)] Permanent flags received: * OK [UNSEEN 15] first unseen message in /var/spool/mail/num received: A00033 OK [READ-WRITE] SELECT completed sending : A00034 UID FETCH 1:* (FLAGS RFC822.SIZE INTERNALDATE BODY.PEEK[HEADER.FIELDS (DATE FROM TO CC SUBJECT REFERENCES IN-REPLY-TO MESSAGE-ID MIME-VERSION CONTENT-TYPE X-MAILING-LIST X-LOOP LIST-ID LIST-POST MAILING-LIST ORIGINATOR X-LIST SENDER RETURN-PATH X-BEENTHERE )]) received: A00034 BAD Syntax error in header fields I don't know what the mail server is, but it does work in every other mail client. Enabling all headers doesn't fix the problem, but this worked before I upgraded to 2.9.x.
From Preferneces-> Account-editor, Set header-prefernces to "Full Headers" and restart Evolution. It will work. If it doesnt work, then paste the gconf-value, for /apps/evolution/mail/accounts.
I came into the office today, and it just worked, no errors at all. I have no idea why. Sorry for the spam. (BTW, the above error messages occurred with "Full Headers" selected.)
OK, I was wrong. The error messages *don't* occur with "Full Headers" selected, but do occur when "Basic + Mailing List" is selected. Regardless, this breaks evolution out of the box, but with *no* warning to the user. They think everything is working, but they just get no new mail.
By the way... the beep in the printf(In reply to comment #24) > I have committed my patches to the HEAD. I have added a g_print statement to > print the HEADER string that will be sent to the server. I will keep this bug > open until I remove the g_print statement that I have put in. The printf and the "\a" on it are still present. Will they be in the big .0 release? I don't think it's a good idea..
\a needs to be removed and the entire statement should preferrably be executed iff the DEBUG flags are on.
The beeps appear to have been fixed in SVN trunk already. http://svn.gnome.org/viewcvs/evolution-data-server/trunk/camel/providers/imap/camel-imap-folder.c?r1=7628&r2=7654
The patch is committed after the 2.10 tarballs are out. Fix will come in the next release.