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:
Well, to be precise, ACAP does not enforce any syntax, but the gatweway
between ACAP and the data store may. For example, ACAP will accept the
data, pass it to the routines to store that data, and those routines may
cause the data to be rejected. This was dicussed at the ACAP meeting,
where I believe the consensus was that the ACAP datasets did not actively
do syntax checking but the backend was allowed to reject data. My argument
was for a good method to find out any format or syntax to allow for a generic
client to determine 'what is acceptible'. (I will be coming up with a
'datasets' dataset that I will hope that people will use for their dataset
definitions. )
\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")"
This way the dataset knows very little of the structure of the filters, and
it is easy to extend.
Hrmmm... I can see why you might want to do this, but I see problems. I
might want to create a script for a given sub-mailbox or a script where
I took mail I wanted to deal with and do something, and as the default
bounce the message. These would be hard to convey with an entry by
entry basis, as would any idea of including other files. I would rather
see something like:
\sieve-filter\users\fred -> filter.name = "main filter"
filter.script = "if () if() dodefault"
and have the backend verify the script when the script is set up.
For example, my backend verifies the script and only generates and
updates the 'compiled' script when it detects no errors.
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.
This gets hairy fast... how do you differ between a script that is supposed
to be run from an IMAP section and one that is not? Unless you have a
modifier at the top that says 'ENFORCE-EXTENSIONS <x> <y>' where <x> and <y>
are extensions that must be supported, it gets difficult.
The other question is what to do when a script fails? If you have one
operating mode 'when MTA is about to put in mailbox', you do not have to
worry about different modes and you just make sure to only update the
current script version when the script is valid. Adding different modes
will start to make the script knowledgable about where it is run from,
how to send any errors to the user to get them to fix the script.
regards,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 576-3873 http://www.wildbear.on.ca/
Author of SLMail for 95 & NT (http://www.seattlelab.com/)