On Thu, 2004-05-27 at 15:56 -0400, JP Rosevear wrote:
On Thu, 2004-05-27 at 09:56 -0400, Michael C. Neel wrote:I know what spambayes is.Quick list of imap filtering: 1. Download message, make it as deleted 2. Check message for spam clues, place results in headers 3. Upload checked version to server 4. Purge deleted messagegive me the actual rules. not the made-up-my-own-syntax rules that don't correspond to any evolution filter rules.Jeff, don't bother, it's clear you're not reading my emails. Those steps are what spambayes does, which I doubt your assertion that you know about spambayes. As I have said before, there are no evo filter rules inplace.Well, its mostly in this thread but to be fair I had to go back and read all your mails in this thread to pick out the various pieces of what your setup was, as it wasn't all in one place (hopefully i get it now). Anyhow it appears the bug is known and is simply Evo (correct me Jeff or Michael if I'm wrong) not picking up the deletion flag on the server (since SpamBayes writes a modified message back to the server and marks the original for deletion). Hitting Send/Receive or switching folders *might* help.
right. a few more notes: 1. When an IMAP client changes the flags on an IMAP message (or messages), the other clients are supposed to get untagged STORE responses along with the next command that they send (assuming they are looking at the folder where the changes occured). The Evolution bug here is that (assuming the IMAP server is actually sending these untagged STORE responses - not all servers properly implement this feature) the IMAP code drops those untagged STORE notifications if the command it just sent did not explicitly expect these responses (or, at least in some conditions it does. I forget if it ignores them in all cases or not tho). As jpr said, switching to another folder and then back again will force Evolution to re-scan the message flags and so *should* then pick up those changes *assuming* of course, that you did not changed those message flags in Evolution before switching away from the folder. If you changed the flags of any of the messages that spambayes also changed, all bets are off for that subset of messages (switching away from a folder causes Evolution to sync its own versions of the flags back to the server - but ONLY the flags that were changed in its interfaces). That said, 1.5 is improved a little tho still not great. Michael started working on a new IMAP plugin called libcamelimapp.so and I had started woking on one called libcamelimap4.so (current one is just called "libcamelimap.so") which aim to remedy this bug (which extends to more than just flag updates, Evo's current imap code pretty much drops most unsolicited responses). So, in summary, as long as you don't change the flags of any of the messages that spambayes changes, switching away from the folder and then back will update Evolution's view to match. 2. Note that even were this issue fixed, you'd still have duplicates in each of your folders - just one set would be marked as \Deleted. Because of the way IMAP works, \Deleted messages aren't actually removed from the folder until you EXPUNGE. Depending on your Evolution configuration, Evolution might show you these deleted messages with a strikeout or it might hide them from you and just show them in the virtual Trash folder. 3. If spambayes were to be fixed to issue an EXPUNGE command after it re-uploaded the modified messages to the IMAP server, then you probably wouldn't have this problem. Jeff -- Jeffrey Stedfast Evolution Hacker - Novell, Inc. fejj ximian com - www.novell.com
Attachment:
smime.p7s
Description: S/MIME cryptographic signature