Re: Moving forward ...

[snip]
> > > 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.

Its early and my parser simply crashed on this one. :) All I'm trying to
say is that the labelling spec needs to consider that MUAs and MDAs have
a vast array of parsing capabilities and we need to consider that when
dealing with a multiple filter chain.

We need to consider:
1) multiple filters attempting similar classifications
	ie: dnsbls at the gateway edge, followed by content filtering at
a second tier.

2) multiple filters attempting different classifications
	* virus, spam, other content filters


> 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.

I wouldn't have actions determined by the filters.  They simply need to
label a message and actions would be determined downstream.


>
>
> --
> Laird Breyer.
>