GNOME Bugzilla – Bug 654480
Mark as Junk is not reliable
Last modified: 2011-07-30 16:26:03 UTC
If a newly arrived SPAM is marked as junk with respective button, it (properly) moves to Junk folder (or virtual folder). However, no action is being done via IMAP (I am monitoring with CAMEL_DEBUG=imapx ), and next folder rescan shows SPAM messages in the INBOX again. Always happens when "bogofilter" is selected as spam filter, and sometimes when "SpamAsassin". Also there seems to be no control to move spam to custom folder.
(In reply to comment #0) > If a newly arrived SPAM is marked as junk with respective button, it (properly) > moves to Junk folder (or virtual folder). Actually it doesn't move the message anywhere. It tags the message as junk, such that it appears in the Junk search folder for that account. The message list is programmed to not show messages tagged as junk in folders other than the Junk search folder. We probably need to make sure we synchronize the folder after tagging messages.
that is what concerned me - no IMAP activity at all means whatever tag wasn't propagated to server. After activity or folder change, it is forgotten. Switching to Junk vfolder and quitting app results in that email (properly) being deleted. Another observation: after email was marked as junk, it is in Junk vfolder, but upon entering then leaving that vfolder, email disappears from there (tag is forgotten). No surprises to find it back in INBOX. Navigating to another real folder on same IMAP does not get the tag to disappear. Even navigating to another server's real iMAP folder keeps junk in place. Enter-leave junk is not the only way to trigger the bug (stuff reappears after a while during subsequent IMAP update) but probably easiest way to reproduce. Could be different issue tho.
This is the response I'm getting from my IMAP server. The end of the PERMANENTFLAGS response is key. * FLAGS (\Answered \Deleted \Draft \Flagged \Seen $Forwarded $MDNSent Forwarded $Junk $NotJunk Junk JunkRecorded NonJunk NotJunk $has_cal $Label2 $Label3 $Label1 i'm_a_new_label i_am_a_label $Label4 $Label5 testing receipt-handled) * OK [PERMANENTFLAGS (\Answered \Deleted \Draft \Flagged \Seen $Forwarded $MDNSent Forwarded $has_cal $Label2 $Label3 $Label1 i'm_a_new_label i_am_a_label $Label4 $Label5 testing receipt-handled \*)] junk-related flags are not permanent It seems the $Junk and $NotJunk flags cannot be set permanently on the server, but they do remain set in the local folders.db database. I suspect what's happening is when we read the flags back from the server in a different session or even a different connection, the absense of the $Junk and $NotJunk flags on the server is clobbering the junk flags in the local database.
Think I got it. Fixed for Evolution-Data-Server 3.1.5: http://git.gnome.org/browse/evolution-data-server/commit/?id=9538392df91ea9c46c1598feab01460951c5176e
Thanks, that was really quick fix. Can I use git evo-data-seever along with stock evo from F15, or should I switch to git alltogether? Sorry about the noise, but I guess answer would be interesting for all bug watchers. TIA
I'm not going to push this to the stable 3.0 branch since I'm not very familiar with IMAPX and it's entirely possible that I broke something else. Use git now or Fedora Rawhide once 3.1.5 is released.
*** Bug 650293 has been marked as a duplicate of this bug. ***
I've applyed fixes to 2.32.3 and it works. For two days no regressions. I think it's worth to backport patch, but decision is yours :)