Question about Sieve and "filters"

[Michael Fair]

> Hi Michael,
>
> --On Tuesday, July 8, 2003 9:38 PM -0700 Michael Fair
> <michael at daclubhouse.net> wrote:
>
> | What do others think about this?
> | Would this simple "pass through" filtering be useful?
> | I'm primarily thinking of Spam catchers, Virus Scanners,
> | and any other use where shoving the email through an
> | external application would be useful.
>
> First off there is a general reluctance, from a security standpoint, of
> allowing sieve to call out to arbitrary bits of code. I suspect that would
> frighten most sysadmins if users were allowed to write their own bits of
> code to run via sieve.

I totally agree that end users should not be allowed to write their
own code.  I was thinking that sysadmins could pull from a pool of
well known plugins as well as write their own.  These would then
become valid "filters" for use in the 'filter :modulename' command
at that site.

End users would have absolutely have no control over which plugins
were in place (other than telling the sys admin what they would
wish to have).


> - I would envisage a plugin architecture that allows different spam/virus
> check systems to be used, but the user does not get to choose which -
> that would be a compile/configuration option for the server admin.
> The main goal for these extensions was to actually remove the need
> for end-users to know about the particular spam/virus test system in
> use, which would otherwise require them to tailor scripts specifically
> for those systems. The new tests allow scripts that do spam/virus
> checking to be portable across different systems, and to also allow
> sysadmins to change spam/virus checkers without having to have
> users change all their scripts. Given that spam checking tools
> are changing so rapidly right now, this solution would be really useful.
>
> <http://www.ietf.org/internet-drafts/draft-daboo-sieve-spamtest-03.txt>

I disagree that:
1) The only two useful email classifier modules are spam and virus tests.
2) The addition or removal of an email classifier should require a
   recompile of the Sieve server.


However, I completely agree that:
1) The available plugins should not be controlled by the end user.
   I had never envisioned that this would work that way.  End users
   need to know what filters are available to them, but this not
   like a web cgi installations where people get to write their own.
2) There should be an abstraction filter for common stuff like spam
   and virus checking where sysadmins can change the implementation.


So let me see if I can strike a compromise here.

How about doing something like:
filter :spamtest
or
filter :virustest

It still maintains the spamtest/virustest abstraction, but it
provides a language based mechanism for adding other filters.
Adding other filters doesn't have to be easy, though I don't
believe that it should require a recompile of the sieve server.
The modules should have their own configuration files/options.
I have no attachment to how the modules should be added,
removed, programmed with.  I really wouldn't even vehemently
argue with requiring a recompile though I do disagree.

I see filters as being used for three things:
1) Email classification (Spam/Virus/Folder group/Site specific class)
2) Email transformation (Wrap Spam in an attachment/Add a header field)
3) Injection into outside systems (Archive a copy/Notify something/SMS)


Regardlesss of whether or not you can live with the whole
'filter :module' idea.  I do have one other extension to
this kind of filtering and that's storing the return code
or string the module outputs.  Card based languages like
SuperCard et. al. have a variable called "it" which holds
the result of the last function called.  I was thinking
something like this could work very well for Sieve.

For instance, imagine the following (constructed for example
of usage not good logic design):

if header :matches "List-Id" "<(\w+)@"
{
    fileinto it;
}
elsif filter :spamtest "ge" :comparator "i;ascii-numeric" "3"
{
    fileinto "Spam";
}
else
{
    filter :virustest;
    if it :value "eq" :comparator "i;ascii-numeric" "1"
    {
        fileinto "Virus";
    }
    else
    {
        filter :folderclassify;
        fileinto it;
    }
}


I have no real attachment to the use of "it".
Any other fixed name will do -- "result" perhaps?

This would give Sieve its one and only variable.
If "variables" are truly an evil thing, think of it as
a function that looks up the return code from the last
Sieve command to return a value.

-- Michael --