GNOME Bugzilla – Bug 317439
Incoming mail not always filtered/junk after upgrade
Last modified: 2007-01-09 20:37:34 UTC
Please describe the problem: Upgraded from 2.2.3 to 2.4 when upgrading to Gnome 2.12. When I hit Send/Receive mail is not always checked for junk and my filters aren't run. This mainly only seems to happen if one new message comes in. If 3 or so come in when hitting Send/Receive it seems to work. Also when starting the app in the morning mail is always filtered and junk run. I will try to test more scenarios. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
what kind of account? POP, IMAP, exchange, groupwise? :-)
Sorry. IMAP to Exchange 2000 Server. Playing some more I have found that selecting "Check for new messages in all folders" under Preferences->Mail Accounts->Receiveing options seems to make it filter and junk all the time. Seems maybe like a timing issue since with this option on it takes longer to Send/Receive where with it off it only seemed to check if 3 or messages came in.
Still an issue on Evo 2.4.1. Having the check all folders helps but it will occaisionally not filter some. I did notice that the Total messages count for the Inbox shows it as an unread message and not new.
I'm having the same issue, also in IMAP ("imap" provider) with a "Microsoft Exchange Server 2003". Sometimes one mail is going through filter, but frequently none is filtered.
One more thing : the suggested sometimes-work-around doesn't seem to work much for me. Setting "Check for new messages in all folders" doesn't make much new mail go through the mail filters.
Poke. Poke. It seems worse now that I am not using Evolution Spam checking with SpamAssassin. I now have have the server tagging SPAM and usually 50% of the time Evolution doesn't run the filter leaving SPAM and Mailing List messages in Inbox. I have to highlight and run Apply Filters.
I see the same thing in 2.5.90 right now - most of the time new mail isn't filtered, at least new mail which is present in the mailbox the first time evolution connects in a session.
I removed and recreated my filters, and they seem to be working properly now. In addition, if I applied the old filters by hand using the Message menu, I got a message about having no handler for type email:. I don't get that with the newly created message. I'm not sure what version of evolution I created the old filters with.
I also have this problem. Rewriting the filter worked for imap but not for imap4.
I am using Evolution 2.6.x, i dont see this bug. Since these bugs are random bugs one who is facing this issue can paste 'CAMEL_VERBOSE_DEBUG' traces in bugzilla. If there is any sensitive info that can be deleted from traces and then pasted/attached here. export CAMEL_VERBOSE_DEBUG=1 in a terminal, launch evolution in same treminal. Paste debug traces displayed in terminal.
Created attachment 67732 [details] Evolution filter not run camel debug
I caught one. I am running 2.6.1 Evolution now. Three messages came in. Two were SPAM that got through the server bays filter. The freeTDS message is ML message that should have got moved to a folder. After I cut and pasted this I manually applied filters and moved fine.
Reopening this bug based on Camel debug, but it doesnt seem to have useful info. rdavis: if it is possible attach filters.xml file, that might help maintainers to fix this issue else mail it to psankar@novell.com/ vvaradhan@novell.com.
Created attachment 69972 [details] filters.xml
I am also hitting this bug (a real pain when you use evolution with hundreds of mails per day). If that can help : it wasn't hitting me with the Imap4 provider, but only with the Imap backend. With evo 2.6, the work around was easy, and consisting in only using the imap4 provider; but now with evo 2.8, I have no workaround, since the imap4 backend seems to have been removed. I think that this bug deserves the 'NEW' status. I can help provide information and/or test a fix. Thanks you.
yepp. :-) imap4 has been removed because it was an unstable, experimental provider, see bug 324118 for more information.
After some debugging, many printfs, recompilation, sniffing etc. I was able to find out that the reason for that bug is the unreliability of the imap "recent" flag. From this, I found out that a few bugs are already registered for this issue. -> Marking as a duplicate of #324804 but has the more extensive and recent discussion (Note that there is a works-for-me patch in #356092) *** This bug has been marked as a duplicate of 324804 ***