GNOME Bugzilla – Bug 230470
IMAP filtering doesn't work with more than one client
Last modified: 2007-01-09 20:32:12 UTC
I have two filter rules set up (attached to the bug). One runs a program to see if the message is spam and colors it blue if so. Another one filters out mail based on the X-Spam-Flag header on the mail and moves it to a separate mailbox. When I select a big block of emails and select "Apply filters", it seems to work fine, but it doesn't apply them when I get new mail in. And yes, I do have "Apply filters to new messages in INBOX on this server". The thing is, one of the filters is a pipe-to-command filter, and it appears to be run because it's updating the mtime of the files on disk, but the actual actions don't seem to be run.
Created attachment 41469 [details] My filters.xml
I created a couple of imap filters, and they worked fine with courier and cyrus. I tested 'sender contains' and 'specific header'. Can you attach a CAMEL_VERBOSE_DEBUG=1 log of evolution-mail? Perhaps the processing on the server is saying that the new messages aren't RECENT. They need to have the RECENT flag set to be filtered.
I'm having a hard time duplicating it now; it seems to work. Aren't those the best? Would using a number of different clients to access my IMAP box simulatenously affect the RECENT status? I usually leave an Evolution running at home as well as my laptop at work. I think that the one at home is in offline mode now, which would explain why I am not seeing the problem now if it would otherwise change the RECENT status.
yea, it's possible that the other client saw the messages first and thus the \Recent flags were removed.
Okay, that's almost certainly what was happening then. Bummer. Is there any way around this?
Not currently. Its the most reliable way to only process messages once, since the state is on the server. Maybe we could keep track of the last UID we processed on a given client?
That's what I was thinking, but I didn't recommend it because I don't know what I'm talking about. :) RFC 2060 says: "Unique identifiers are assigned in a strictly ascending fashion in the mailbox; as each message is added to the mailbox it is assigned a higher UID than the message(s) which were added previously." So it sounds like it might work. There's a note shortly thereafter where it says that UIDs can be regenerated, however, in which case this wouldn't work, but it strongly discourages that, and I'm not sure how common it is.
the only problem with this is: what if I decide to move a message from another folder (because it was wrongly filtered the first time?) back into the INBOX? Oops. It gets filtered back to that folder again. so whatever solution we decide to user, we have to figure out how to work around that I guess.
yeah but we have that problem *anyway* jeff :) see bug 215672
*** bug 231355 has been marked as a duplicate of this bug. ***
we will not be fixing this (ettore told me to close all IMAP filter bug reports as they are not possible to fix)
*** bug 234496 has been marked as a duplicate of this bug. ***
*** bug 238508 has been marked as a duplicate of this bug. ***
*** bug 234067 has been marked as a duplicate of this bug. ***
*** bug 236003 has been marked as a duplicate of this bug. ***
*** bug 236592 has been marked as a duplicate of this bug. ***
*** bug 240774 has been marked as a duplicate of this bug. ***
Apparently Mozilla 1.3+ has fixed this unfixable problem as their mail client properly detects new mail. Perhaps their source for INBOX incoming mail detection and filtering could provide a solution.
I still suggest server-side filtering :-) it's the only way to do it if you are going to have multiple clients accessing the imap folders. as soon as you have multiple clients all trying to filter stuff, all hell breaks loose.
*** bug 246347 has been marked as a duplicate of this bug. ***
it is impossible to detect new mail *reliably* with multiple clients. We could track the uid's for the folder, but we then have the following problems: - another copy of evolution (or insert any mailer) running at a different time on the same server would re-filter messages, every time - if the uidvalidity ever changed, which they do, you would have to discard all knowledge of downloaded uid's, and re-run the filters on everything in inbox - multiple concurrent clients would all do the filtering again and again. if those limitations are considered reasonable, then perhaps that is an acceptable enough solution.
*** bug 243826 has been marked as a duplicate of this bug. ***
*** bug 249505 has been marked as a duplicate of this bug. ***
Marking as a duplicate of #324804, which is about same issue (related to the unreliable recent flag), but has the more extensive and recent discussion. *** This bug has been marked as a duplicate of 324804 ***