Re: New Filtering Draft version posted

On Wed, 2004-06-23 at 20:14, John Levine wrote:
> >More to the direct point, I think that the two different directions
> >we are in,
> >
> >	1:   define a language for communicating gathered data
> >
> >	2:   define mechanisms for shared Bayesian tuning feedback
> >
> >easily warrant creating two documents.
> 
> 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, with either
a designated e-mail addresses to forward to, or a magical IMAP folder.

Knowing this, the problem for making 2 interoperable 
out of the box is to suggest ways to autoconfigure the Is/Not-Junk button
for POP mail: A MTA with integrated IMAP can just sort things server-side.

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

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 has a set of MTAs that share a configuration,
why don't they just keep the configuration in a file on a caching NFS and
reload it periodically?  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?


David Nicol