GNOME Bugzilla – Bug 215672
IMAP filters re-apply on message move
Last modified: 2009-12-11 04:26:03 UTC
Please fill in this template when reporting a bug, unless you know what you are doing. Description of Problem: When I move a mail from a filtered folder back to my Inbox, the filter re-applies itself and moves it back to the folder it was originally in. Steps to reproduce the problem: 1. Setup up a folder and filter messages from a mailing list into that folder. 2. When mail comes in it will move to the appropriate folder. 3. Try to move a message from the folder to the inbox. 4. Watch it move back into the folder it was moved from. Actual Results: The message ends up back where it started Expected Results: Since filters are only supposed to be applied on incoming mail or when filters are manually applied, I expected the mail to be left in my inbox. How often does this happen? Every time. Additional Information:
I assume this is because your IMAP server is marking the moved message as \Recent... and all \Recent messages get filtered by Evo on IMAP. I don't think the server should be marking the message as \Recent, so I *think* it's a server bug but I'm not 100% sure. I'd have to reread parts of the IMAP spec and also see how we decide to filter messages in evo's imap code...
Um... no, the server is correct to call it \Recent. Blah.
okay, so the only way I can think of to fix this is to add some X-Evolution-* header that says that the message has already been filtered so we don't filter it again. But, if we do that, then we slow the process down a HUGE deal because that means we'll have to modify the message and upload it to the IMAP server again instead of using the handy COPY command on the IMAP server. Joy. why do you want to move the message back to the Inbox for anyway? *sigh*
If the server supports UIDPLUS, it's easy to recognize the message. If not, we can remember the md5sum of the headers or something like that.
hmm, i thought filtering was only supposed to apply to inbox. Perhaps i rooted it up, thats what it was supposed to do.
ok so i misread this the first time around. You're wrong. Filters do not apply to incoming mail, not for imap. Imap has no notion of 'incoming mail' that it tells the client - apart from setting the 'recent' flag, which is what we use. Using uidplus doesn't help the servers that dont support it (which is a lot), so its not a suitably general solution. More servers support arbitrary flags: we could use an arbitrary 'user flag' in the append to flag it. Or even if they didn't, then use the 'flagged' bit, its very unlikely a truly recent message would have the flag bit set, and we could flip the bits off when we receive any "recent & flagged" messages.
hmmm, I don't like the idea of using the flagged bit, it's possible for me to copy a flagged message over to my IMAP INBOX. I probably wouldn't want it to be unfalled. if we can do the user-flag bit, then we should do that otherwwise just forget it I guess.
This bug has been fixed in 2.28.0 afair This version is no longer maintained, which means that it will not receive any further security or bug fix updates. The current stable GNOME and Evolution version is 2.28. Can you please check again whether this issue still happens in Evolution 2.26 or 2.28 and update this report by adding a comment and changing the "Version" field? Thanks a lot. Again thank you for reporting this bug and we are sorry it could not be fixed for the version you originally used here. Without feedback this report will be closed as INCOMPLETE in 6 weeks.
*** Bug 350326 has been marked as a duplicate of this bug. ***
Closing this bug report as no further information has been provided. Please feel free to reopen the bug if the problem still occurs with a newer version of GNOME 2.28.0 or later, thanks.