No, I was thinking of of more complex scenario then just standartized xml
filter list. While I agree that current spam filters implementations often
use different methods for representing and getting rule set, I do not
think we're at the point yet that we can not create a standard
distribution mechanism and having central database server can
often be easy (it may not have to be a requirement, i.e. one can only
implement MUA->server filter update mechanism but large company/network
with many incoming mail server would really benefit from cental server and
if we standard way to represent rules, going futher to distributing them
is not really such hard work, many implementations for such distributions
already exist, its just a metter of choosing right one)
And I was thinking futher along the line of creating standard header lines
on what filter has been used (for client MUA to know in standard format)
and in order to allow for distributed filtering systems and removing
necessity of applying same filter twice.
At 3:07 PM -0800 3/22/03, william(_at_)elan(_dot_)net wrote:
Also as far as saying protocol, it would not necessarily be new protocol,
but could be based on LDAP with defined scheme. But we would need to
evaluate several protocols and create list of requirements like this is
being done at CRISP working group working on new whois protocol.
What do you think of the above idea? I know there are lot of people on
the list that represent anti-spam filtering software solutions, do you
think you could work together to create standard for this?
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, but still have a common
front-end for the settings. The back-end filter can provide a
capability list. The MUA or filter client would let you specify the
values--providing custom interfaces for the ones it understood, if
necessary, and generic interfaces for the rest.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg