On Fri, 28 Mar 1997, Randall Gellens wrote:
If the filters are being run by the client, then the client should run them
after receiving the message via POP and before storing the message in a
folder. In this situation, "final delivery" means delivery via POP.
Ok.
If a filter script looks like a simple set of "if A then do B" statements,
this works. If a filtering script is more complicated -- nested
conditionals -- I don't think the mapping is so clear.
I also have concerns with extensions. In the case of an IMAP server doing
filtering, the extensions supported will not be clear to the ACAP server
accepting scripts. The ACAP server should not be expected to verify the
syntax of scripts; the store-this-script-client needs to do that, and I'm
not sure how it finds out that the IMAP server supports some random
extension.
ACAP does not verify syntax on options. There really isn't any "mapping"
when storing filters in ACAP. The way I see the filter dataset, it is very
simple: just a set of entries, each entry consists of an entry (name)
attribute and a filter attribute. The entry attribute is any unique handle
assigned by the filter generator (probably the client), and the filter
attribute is just a text string. For example:
\user\fred\filters
dataset.entry = "make-money-fast"
filter = "if = ( subject, "make-money-fast" ) then trash"
dataset.entry = "peggy-sue"
filter = "if = ( from, "peggy-sue(_at_)some(_dot_)address" ) then file
("personal")"
I'd like to allow nested conditionals -- this makes things a little bit more
complicated. Also, guaranteeing the order of evaluation might be useful,
but might be difficult to work out with ACAP.
The best I could come up with to solve this was to just demand that sites
advertise supported extensions and if filtering fails, messages get dumped
into INBOX.
Yes, there needs to be a way for a site to advertise which filter
extensions it supports, and there needs to be a default action for
unrecognized filter clauses or actions. I think filter extensions should
be advertised as part of advertising filtering support, in an IMAP
CAPABILITIES. This does beg the question of how to advertise non-IMAP
support, but at least it is a start. I agree that default action should be
to file in INBOX.
Advertising filtering support in CAPABILITIES only answers the question for
IMAP, but it might be a workable approach.
--
Tim Showalter
tjs(_at_)andrew(_dot_)cmu(_dot_)edu