[Top] [All Lists]

Re: Filtering Infrastructure (was "Re: Who will write filtering scripts?")

1997-03-28 19:14:23
I'd go along with either approach.  Personally, I think having each rule in
its own attribute is easier to manage, but it's not something I feel very
strongly about.

Here is what I think we need to get server-based filtering moving along:

(1)  A very simple filter language.  Minimal functionality, easy to
implement, with an extension mechanism.


(2)  A spec for how to store filters in ACAP.  If all of a user's filters
are stored in one attribute, it seems kind of silly to have a whole dataset
for it, but I don't really care that much.

depends... but can be done either way...

(3)  A spec for how and when filters are to be executed, and what to do in
case of errors, unrecognized elements, etc.  Also, how to notify users of
the filter results (if such notification is desired).  Plus, how a delivery
entity advertises support of filter extensions.  It seems to me that any
unrecognized filter should result in default action (file in inbox).
Simple mail messages could be used for notification.  An IMAP CAPABILITY
keyword seems to make sense for advertising support of filtering (and
filter extensions), but does tend to blur the lines between the protocols a
bit.  But it seems the most logical place to start.

This I wonder about.  We may have to develop profiles that are used depending
on its applicability.  Personally, I think any filtering should be done by
the MTA, and I see little applicability in keying some filtering off of the
opening of a mailbox.

Jack De Winter - Wildbear Consulting, Inc.
(519) 576-3873

Author of SLMail for 95 & NT (