Re: [Evolution] Disable header changing in IMAP?

[Not Zed <notzed ximian com>]

On Thu, 2004-05-27 at 10:05 -0400, Michael C. Neel wrote:
>     
> >         Ahh, so you have spambayes downloading messages, then changing their headers, then re-uploading them?
> >         
> >     
>     
>     Yes, it's what i've been trying to say =)
>     
>     
> >         Don't run both clients at once I guess.  What you're doing is really nasty, you should do it on the server if thats what you want.  Evo has 'known issues' with some servers and multi-access to the same folders at the same time.
> >     
>     
>     Yes, there problem doesn't exist, but that leave option a) no spam filtering or b) no email reading, not really good either way.
>     
>     So yes, it would have saved alot of trouble if someone said this was a 'known issue' from the start, instead of telling my I didn't have my setup correct.  Are there any workarounds for these cases?  And what exactly is the root cause; if it's possible to alter source I can to solve the problem.
Yeah sorry - miscommunication.  It just sounded like you were saying evolution was uploading messages, I didn't realise you had another client doing that.
>     Last, I can tell spambayes to log all dialog with the IMAP server when it run, very handy to see what it's doing.  It there a way to enable it in evo that would help as well.  Barring that I can try with some tcpdump settings, but I'm not sure I would know the source app talking because the both log into the same server with the same account.
Run evolution with CAMEL_DEBUG=all (for pre 1.5.5, CAMEL_VERBOSE_DEBUG=1) set in the environment.

It will log a lot of other crap too though.

It's probably that when evo goes to sync its flags it thinks you changed the flags on this end, so stores that on the server.  Some IMAP servers wont send flags when another client updates them (few do actually) for concurrent access.  And even if they do, they can't if the flags are set on the 'non-selected' folder, which roughly equates to the one you're looking at currently - this is an IMAP protocol limitation.

Yeah evo is over-enthusiastic about caching the flags (we've had some complaints about this), and yes it could probably do something slightly different to mitigate this in the case of shared access, but ... it doesn't at present.  And even if it did, there will still be conflicts that have to be resolved one way or another.

Michael Zucchi <notzed ximian com> Ximian Evolution and Free Software Developer

Novell, Inc.