Re: goals of this subgroup, was New Filtering Draft version

On Friday, June 25, 2004, 12:04:25 AM, John wrote:

>>> >	1:   define a language for communicating gathered data
>>> >	2:   define mechanisms for shared Bayesian tuning feedback

>>> Of course.  When I started up this subgroup, I was more thinking of
>>> the first.  You need someting like 1: to do 2:, and 1: is more
>>> generally useful, e.g., to push out updated filter rules from a
>>> central management point to a bunch of MTAs.

>>Sorry to be contradictory, but 1 is not a prerequisite for 2.
>>Existing shared-tuning designation engines use the whole message for
>>tuning, ...

JL> I should have been clearer, I was thinking about languages for
JL> communicating filtering advice, not just raw data, e.g., don't take
JL> mail from this IP address, award 15 whitelist points to mail with
JL> "swordfish" in the headers, etc.  There's ad-hoc ways to communicate
JL> some of these, like DNSBLs for IPs and rsync'ing config files among
JL> systems running the same software, but I was hoping for something to
JL> permit heterogeneous filtering engines to send realtime updates to
JL> each other, sort of the way that Brightmail pushes out filter rule
JL> changes to client filtering boxes all over the world.

I don't have time to get heavily involved in this again right now,
however there was at one time a fair amount of activity on developing
an XML based model for declaring and sharing filtering (policy) configuration
information.

It was based on SortMonster's internal research and could be adapted
to hierarchical as well as dynamically peered sharing configurations -
including mixed environments with only partial compatibility.

At the core of this example is the idea that any definitions or tuning
parameters can be expressed in the framework. The filters driven by
these parameters develop a profile of a given message on the local
system. That profile can then be used to apply the local policy which
is built of definable actions.

Actions and filtering elements can be well known (such as "source
matches SBL" so "tarpit") or can be made of proprietary actions
supported only on the local system by scripts or other software.

Compatible elements can be shared or not shared, imported or not
imported between systems based on a local security policy. The network
of interlinked security policies can be defined to extend only through
a given system - or extended beyond those boundaries to participate in
some more globally available mechanisms (ala WOT et al) or some mix in
between.

You might start there.

A loose prototype is here:

http://www.sortmonster.com/ASRG/index.html

Hope this helps,
_M

Pete McNeil (MadScientist)
President, MicroNeil Research Corporation
Chief SortMonster, www.SortMonster.com