Re: Moving forward ...

On Feb 26 2004, Jesse Dougherty wrote:

> > > * filtering decisions are dependant on the state of the filtering 
> > > (virus definitions, software version) at the time of 
> > message scanning 
> > > resulting in different results for the same message at different 
> > > times.  It is important for filters to be able to add meta 
> > data to the 
> > > label.
> > 
> > This is bad. I'd much prefer a system where my filter can 
> > easily ignore anything done by other filters. Let the user 
> > decide how to 
> > integrate all the various recommendations.
> 
> Yes, but the headers have to express this information in a way that
> lotsa different rule systems can understand them.  (from procmail to
> simple header pattern matching)
> 

I'm not sure I follow your meaning. Generally, the results of
filtering by different algorithms are meaningless across all
algorithms. 

For example, dbacl calculates a number of bits of
information per token, relative to a probability measure.
It's meaningless to any algorithm which doesn't have access to the
probability measure used. It's even meaningless to dbacl when the 
probability measure changes after retraining. I wouldn't expect any
algorithm to use this information. 

Now dbacl also outputs a verdict, ie spam/notspam as a category name.
This is marginally useful to other filters, who can use it e.g. to 
file a message into a folder named spam/notspam. 

Are you saying that it is desirable for filters to output a set of 
standardized headers which can be used for specific purposes?
e.g something like "X-Folder-recommendation: spam". If that's what you
have in mind, maybe it would pay to list all the actions an agent
might want to perform on a message first. 


-- 
Laird Breyer.