Re: [Evolution] Several issues with 2.12.1

On Thu, 2007-10-18 at 15:58 -0400, David Ronis wrote:
I'm using evolution-2.12.1 on a box that has two unix mbox's:  one the
usual system spool mail file and the other a file in ~/Mail/ that
contains possible spam that is caught by an additional spam filter that
I run. 

By poking me so eloquently on IRC, you just made me get back to this
list, which I haven't in a long time... ;-)

In order to get both to work, I've created two accounts,  each pointing
one of the spool files.  This works, although both accounts appear with
separate Inbox, Junk, & Trash subfolders.  Here're my problems:

1.  I created a filter rule such that all mail in the Inbox of my
secondary spam file should be moved to another folder in my main mail
tree (and yes I checked apply filters in the receive options for this
account).  This doesn't work, even though I can manually select all the
messages and apply the filter with ctrl-Y.

2.  I also filter the mail with spamassassin inside evolution.  This
works for both accounts, but spam is moved to separate junk folders.
I'd like them merged.  Also selecting all the mail messages in one and
trying to manually move them to the other fails.  I get the right
popups, but in the end I can't select the other junk folder (this may be
a feature).

Junk is vFolder (Search Folder). It just displays messages with the Junk
flag set. The messages itself are still physically located in their
original mail folder.

A feature request for physical Junk folders has been filed.

Moving messages out of the Junk folder (same account) will mark them as
non-Junk and make the backend learn them as such. This is *not* what you

Also, you can not move messages to a vFolder, since it (can) be a view
of multiple physical source folders.

3.  When I delete mail the deleted mail ends up in it's account-specific
trash folder (I'd prefer just one, but that's not the issue now).  

Deleting mail actually is "mark as deleted". The Trash (also) is a
vFolder, that just displays all messages marked for deletion. Similar to
the Junk folder, support for a physical Trash folder is a filed feature

There are a couple reasons, why this approach is preferable. For one,
there is no "move" command in IMAP. Same for mbox format files. So a
physical Trash folder would resort to copy the mail, and delete the
original one. Where "delete" is mark as deleted only, unless you expunge
it [1]. Only the latter will physically remove the source mail from the
mail folder. Since this would have to be done per deleted message, this
potentially means rewriting a large file for every single "delete"
command -- which bears quite some speed penalty.

In any event, when I empty the trash, only one of the trash folders is
emptied.  The other just seems to keep on growing.  This is clearly a

Didn't check this in a while, but it sounds like Empty Trash is per
account. Did you ever try opening that persistent Trash folder and try
to empty it?


[1] "compress" in Thunderbird lingo. While Evo Trash behavior might seem
    strange on a first glance, it at least exposes the fact that a
    "deleted" mail actually still is physically located in the source
    folder. TB is really good at hiding this fact entirely from the
    user. Even after expunging the Trash, the believed to gone for good
    data still lurks on disk, until the user actually compresses the
    folders. A security and privacy problem, cause the user is unaware
    of the fact that data *still* exists.
    I have yet to come across a former TB user, who complains abut Evo
    behavior and actually *is* aware of this fact... *sigh*

char *t="\10pse\0r\0dtu\0  ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}

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