(I trimmed the To/CC lines, since everyone's reading the list anyway...)
The filtering draft I've been working on was based on a document that
happened well before we got as worried about ACAP as we are now. It is
basically a flat-file script/program that has a bunch of if/elsif/endif
clauses. I rather like the format, because it means it can be edited by
hand, and it has no particular dependancies on ACAP.
If we take the if/elsif/endif clauses and push them into sparate ACAP
entries, you get the same thing, except you have no guarantee on order of
evaluation, which is a fairly useful thing to have if you'd prefer to toss
out any message you don't filter.
if any-of (header ("subject") contains ("HEY-TIM-ACTUALLY-READ-THIS"),
header ("from" "sender") contains ("wall" "wcw" "weiler" "rob") then
fileinto "INBOX"
elsif header ("to" "cc") contains ("ietf-mta-filters(_at_)imc(_dot_)org") then
fileinto "INBOX.mta-filters"
else
reply message
I dropped your message, because I don't know you, and I think
your message is unsolicited. If this is not the case, send mail with the
subject "HEY-TIM-ACTUALLY-READ-THIS".
.
toss # throw message away, it's probably spam
endif
(This script might actually comply with the syntax I was working on.)
As I understood the example, it could be difficult to get this sort of
split. Did I take too slim a view? The above is a really paranoid
approach ...
I want to advocate an approach that allows savvy script authors to bunch
together similar cases to save space and time.
If the message is from anyone at CMU.EDU then
If the message is from wall then
put it in INBOX.from.wall
If the message is from rob then
put it in INBOX.from.rob
If the message is from shadow then
toss
stop
Else [ Sort on mailing lists here or something ... ]
If ...
... Endif
stop
Endif
toss
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?
What's the difference, other than mailbox names?
I suggest a "normal" action, which is "do whatever you'd do if you weren't
actually filtering this stuff." Under IMAP, it's file into INBOX.
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.
I suspect this is a good idea to have anyway.
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.
I believe the thing to do when a script fails is
* drop the message into INBOX (or the local equivalent)
* drop another message into INBOX, saying "An error occurred...",
although the filtering agent has to be sure not to do this too often
--
Tim Showalter
tjs(_at_)andrew(_dot_)cmu(_dot_)edu