Re: [Evolution] Disable header changing in IMAP?

["Michael C. Neel" <neel mediapulse com>]

> what, you mean in the whole millionth of a second that it takes to add a
> header to an already parsed message?
>
> besides, if the message gets deleted *and* expunged, then evolution will
> remove it from disk as well as remove it from the message-list shown to
> the user. same as if the suer had deleted/expunged the message.

If that was happening, I wouldn't get dups when running evo then would I? =p

> >   Since a copy has to be made, the message id will change.
>
> no it won't.

A copy has to be made by SpamBayes, because it needs to place the result of the spam check into the header as well as it's own ID system.

> > 
> > Again, this does not happen with evo closed, only running.  No I'm not
> > using filters in Evo for my IMAP account (I have one inplace for a pop
> > account, but there is no spam filter on it).
>
> well, evo isn't uploading the mesages with an X-Evolution-Source header.
> I can assure you. If you don't believe me, take a look at the message
> sources via another mailer. they won't have that header.

I know that you guys don't want to even consider this an issue, NIH and all, but Evo is doing something here.  Another possible option is evo is seeing the deleted message and undeleting it, so when spambayes completes and runs a purge the message is not purged.

All in all I switched to evo because the connector was open sourced, but there doesn't seem to be alot of help coming from the novell/ximian side of things for people to install the connector - the connector feels like an abandoned project rather than an open sourced one.  I feel that atm, unless you are using suse of course, KDE offers better exchange integration than evolution.

> > 
> > As an aside, can we not create fake headers when viewing message
> > source?  When someone wants to see the real email source, show them
> > that, not an altered version that doesn't really exist.  Bad enough
> > tracking an email down though a spammers tricks, now my client doesn
> > them too :/
>
> they are used for filtering purposes as well as hints for deciding which
> acount to default the composer to when replying, so no. well, unless you
> can come up with a better idea :-)

yes.  internal database.  keep it internal.  if it doesn't exist in the message, then you are going though steps to put it there on view.  why?  show email source should do just that, not show email source + special evo internal database values masquerading as email headers.

mike