[Evolution] Patch for unreliablity of Evolution's automatic client-side imap filtering

   I have long used Evolution, and have stuck with it for so long
because of it's powerful client-side filtering. Recently I upgraded to
Fedora Core 1 both on my desktops and servers. In the process I upgraded
to Evolution 1.4.5 and Cyrus-imapd 2.1.15. The end result was that
automatic filtering was made almost useless. It only worked for messages
that had come in while I had all clients closed. Otherwise they would
come in, and just sit in the inbox.

   To resolve the issue temporarily I tried switching to sylpheed-claws.
The current version worked for me better than previous versions, but
seemed much slower. It also didn't automatically update folder message
counts without being even slower, and wasn't nearly as aesthetically
pleasing. Another annoying behavior was it froze the whole interface
while it was talking to the server. A few days later I got fed up and
starting hunting for a solution to my problem with Evolution again.

   After looking over the mailing lists and bugzilla I found this was a
known issue that seems to date back to at least Evolution 1.2.1 if not
farther. The Evolution developers seem unwilling to fix it, saying it is
a imap server problem. They do admit that even with a proper imap server
you will still have issues if you open other imap clients. They
suggested using server-side filtering.

   Server-side filtering doesn't really work for me for multiple
reasons. One, I require the ability to filter based on the body of the
message. Sieve, the server-side filtering part of Cyrus-imapd doesn't
allow this. I even found other e-mail clients don't allow filters based
on the body. An example is Thunderbird which doesn't for imap accounts.
Two, I do filtering on three different imap accounts. One is my personal
account, and two are work accounts. My employer requires I keep the
accounts separate, instead of forwarding it all to one of the three.
There are two different servers involved and having to manage rules on
both would be greater hassle than just filtering it client side. Three,
I can only insert procmail into the mix for more advanced server-side
filtering on my personal account.

   The issue revolves around the Recent flag on messages. Evolution uses
this flag to determine if it should automatically filter a message or
not. The given reason for this is to prevent filtering a message more
than once. An example would be a filter is set to move a message from
the Inbox to a folder, but for whatever reason you want to override the
filter and move it back to the inbox. Without the Recent flag check the
message will get automatically moved back to the folder after Evolution
is finished moving it to the inbox. I have observed this myself in the
past, and do find it annoying. On the other hand I found it hundred
times more annoying not to have reliable automatic filtering.

   One thing that points to this being a Evolution bug instead of a
server bug to me is that automatic filtering always works right in the
situation described above where it will automatically filter messages if
the Evolution has been closed while the message came in.

   My workaround/fix for this problem is a simple patch to comment out
the if statement that checks for the Recent flag. Normally it would then
set a variable on each message to control if it is automatically
filtered or not. With the patch the variable is always set, and hence
always automatically filtered. This patch works great for me. The only
exception I have found is it doesn't always do it on it's own if you
aren't in the inbox folder, but switching to the inbox always triggering
filtering. A draw back other than the one mentioned above is this patch
causes Evolution to filter all messages in the inbox, which slows it
down. This is especially true if you let your inbox count get high.

   Below is a url where you can find the patch. You can also find binary
and source rpms for Fedora Core 1.


   If anyone has a better method or patch, please share.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]