On Fri, 2004-03-26 at 23:04 -0500, [EMAIL PROTECTED] wrote:
> Well, I've got to put all that lot into the docs, but here's a quick summary:
> 
> * Spamassassin only. Want another system? Pipe to shell script (Now "Run
> Command").

For those of us who have already been using SpamAssassin, and have users
who use other Mail Clients, it would be really nice if Evo would support
a mode of using SA in which the mail has already been filtered and
tagged with SA.  While the integration of MTA/MDA functions into the
client is attractive to some folks in certain situations, allowing
things to work in a more loosely coupled manner would also be useful.

Right now I use a vfolder to filter for [SPAM] in the subject. I handle
ham and uncaught spam by having local folders called "Surviving Spam"
and "Ham" and moving e-mail to those folders. I then have a shell script
which I run periodically which uses sa-learn to train on these mailboxes
and in the case of ham formail and  spamassassin -d to get the mail back
into it's "original" form and put it in a local mailbox called processed
ham.

I'd like to be able to use the junk and not-junk buttons to do this.

I'm assuming that junk uses sa-learn to train sa that the mail is spam,
and then moves it to junk, and that not-junk trains it as ham, get's it
back in it's original form and then moves it back to the inbox.

I'm not sure what filter junk does.

If Evo could be told to just look at the subject for the [SPAM] tag,
perhaps with a way to override the actual tag and send those to the junk
folder, then the other functions (junk/not junk) would just work.  It
might take a little more to work with site-wide filtering, but I'm not
currently using that.

If I have a filter which looks for the tag, and sets the status to junk,
should this work?


> 
> * The "Local tests only" will check your bayesian methods and known
> suspiciousness tests, but won't use the online blackhole lists and so
> forth.
> 
> * For enhanced performance, start the daemon (as root) and select "Use
> Daemon."
> 
> * Server side spam filtering is almost always better. Local spam filtering
> means you have to download it and then filter and then discard.
> Server-side means it happens before you get there, so you don't have to
> wait for filtration to happen. Although server-side is harder to train...
> (not integrated into Evo in any way).
> 

And that's what I'd like to see a little better integration with server
side filtering.

_______________________________________________
evolution maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/evolution

Reply via email to