There are some issues. Your filter server's capabilities may not be
the same as mine, for instance. But in general, the idea of a common
mechanism for expressing your filter desires (what countries, what
languages, what's the white list, what's the blacklist, what IP's or
RBLs...) is a good idea. We have already done some preliminary work
in this area with our product.
While you could standardize the database<->MTA communication layer, I
suspect that's going to be pretty custom from product to product.
However it definitely makes sense to have a standard mechanism for
getting filter information from the MUA. And (although I shudder to
hear myself say so), some type of XML specification would probably
make a lot of sense here. It has the flexibility such that you could
work with different filter products,
This is why we need some kind of consent-expression framework
(which I'm still trying to come up with a rough draft of) I like the idea
of (optionally signed) XML (shudder also).
Filter Configuration is just Consent Expression
turned on it's head - kind of
Also needed - a classification of message classification methods, so that
the end user can mane (and constrain the employment of) generic or
(specific/proprietary) mechanisms.
You also need a way if passing parameters - I guess - e.g.
probablities/scores
I'm interested in this so that I can build in to my webmail system a UI to
the filtering system which I can distribute better than the current system
which has to dump application specific filter files into the right place in
my MTA filesystem (uggh).
But obviously more general applications would work.
I'd expect consent to be available from a per-domain service such as
"consent.merseymail.com" or "merseymail.com:consent" and be cacheable (this
requires some TTL field).
It's likely such a system would support legislation which requires proof of
consent in advance.
--
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg