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

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

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

>It is troubling that we don't have anyone who has, for instance,
>worked on thunderbird, in the discussion.

If you can find someone, please invite him or her.  We're all
volunteers here, remember.

>Your example, to push out updated filter rules from a central management
>point to a bunch of MTAs, doesn't strike me as something that a standard is
>needed for.  Assuming an enterprise ...

Don't assume it's one enterprise.  Spamhaus.org currently distributes
a DNSBL of places from which they suggest not to accept mail, but they
have a lot more data than IP addresses.  They could usefully send more
out if there were a way they could do it and the remote MTAs could do
something with it.

> Would you mind fleshing out your example a little bit more so I can
> see how a descriptive, standard, extended RFC-2822 header would fit
> into the scenario?

Actually, I don't see any relation to RFC 2822 headers at all in this
scenario, since this is metadata about filtering, not metadata about
an individual message.  Maybe it'd be sent around as e-mail messages
to a disinguished address (filtermaster, say) with a funky MIME part,
maybe it'd be pulled from web servers like RSS.  I'm not picky about
the distribution medium.

Regards,
John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.