At 3:56 PM -0500 3/28/97, Tim Showalter wrote:
On Fri, 28 Mar 1997, Randall Gellens wrote:
It seems to me filtering should be done during final delivery, before
placing the message in any mailbox. This was the filter rules can file,
forward, trash, etc. the message before it has been delivered. Which
software module actually runs the filter rules of course depends on the
implementation.
I agree with you, except this isn't possible in a POP3 environment where
folders are maintained on the client's end only. I believe this is
important because there are a number of people who want to use a filtering
language cooperatively to stop spam, many of whom are not using IMAP.
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.
I think ACAP is the logical place to store the filter rules. In many ways,
filter rules look like a subset of an address book, and so would probably
go in the user's options, perhaps in a new dataset, which would be defined
and agreed to for interoperability.
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")"
This way the dataset knows very little of the structure of the filters, and
it is easy to extend.
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.