Re: [Evolution] Disable header changing in IMAP?

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 message

give 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 and I had started
woking on one called (current one is just called
"") 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.


Jeffrey Stedfast
Evolution Hacker - Novell, Inc.
fejj ximian com  -

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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