Re: [Evolution] Disable header changing in IMAP?

["Patrick O'Callaghan" <poc usb ve>]

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:

* The message appears both in my Inbox and in a List-specific folder.
* 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.

Just my 2 cents ...

poc