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.
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.
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.
--
Tim Showalter
tjs(_at_)andrew(_dot_)cmu(_dot_)edu