> Hi Michael, > > --On Tuesday, July 8, 2003 9:38 PM -0700 Michael Fair > <[EMAIL PROTECTED]> 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 --
