Re: [Evolution] Disable header changing in IMAP?

[Jeffrey Stedfast <fejj ximian com>]

On Thu, 2004-05-27 at 07:03, Patrick O'Callaghan wrote:
> On Thu, 2004-05-27 at 10:46 +0800, Not Zed wrote:
> > On Wed, 2004-05-26 at 17:20 -0400, Michael C. Neel wrote:
> > > > sure you might, since presumably you are getting dups unrelated to
> > > > anything in Evolution itself unless the filters you created in Evolution
> > > > are duplicating the messages (which would mean you set them up wrongly,
> > > > not that they are broken).
> > >
> > > As I've said it happens only with Evolution running.  It does not
> > > happen with Outlook Express.  I have one pop filter running on the
> > > local inbox, which isn't doing anything with the imap account.
> > Well obviously your config is making it do it.  It WONT do it by
> > itself. 
> > > > well, this presumably takes place on the server, so is not an issue at
> > > > all with Evolution's IMAP cache.
> > >
> > > SpamBayes does not run on the server...
> > Ahh, so you have spambayes downloading messages, then changing their
> > headers, then re-uploading them?
>
> I also am getting occasional dups, not in a recognizable pattern but
> they're definitely there:

it's *very* recognisable

> * The message appears both in my Inbox and in a List-specific folder.

you got one from the list and one was cc'd to you.

> * It happens on several lists, not just this one. Some but not all of
> these lists are managed by me and I *know* they're not broken :-)
> * I do the list filtering on Evo. All my filters check only for
> listiness and have the Stop rule immediately after.
> * I do not use the Evo Junk stuff.
> * My mailserver is Cyrus and I use IMAP.
> * The mailserver runs SpamAssassin on every message as part of the
> delivery process. SA files spam in a Spam folder and otherwise leaves
> the message untouched. This happens *before* final delivery to Cyrus.
> * None of the duped messages are spam. It's not clear that SA has
> anything to do with the problem in my case.
> * I don't use procmail or any other filter on the client or server side.
> * The dups are bit-for-bit identical (I saved them and did a "cmp") i.e.
> they are the same message up to final delivery.
>
> I run Evo 1.5.8 on Fedora Core 2 in two places. I never have both
> instances running at the same time. However the Evo back-end stuff *is*
> running at the office when I'm using the home instance, and vice versa,
> so if the filtering is being done by the back-end this could be part of
> the explanation. However both instances are using the same filter rules,
> so why does one of them filter and the other not? (some kind of optional
> builtin rule tracing or logging would be useful here as an alternative
> to running the whole thing under CAMEL_DEBUG which I confess I haven't
> bothered doing).
>
> I'm not saying this is necessarily an Evo bug, but there's clearly an
> unwanted interaction going on which I'd like to track down.

it's not anything to do with evolution.

Jeff