Question about Sieve and "filters"

[foobar]

On Wed, 9 Jul 2003, Michael Fair wrote:

> 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.
>

Yes,

my idea (ripped from apache):

Like in apache we have DSO Support we could have it in sieve too so we
don't need re-compile, just restart or so.

We have handlers like in these modules,

mod_start - pre-load everything needed.
mod_handleX - give reference in, process, give status out / rewrite
message
mod_end - shutdown module

where X is 'handletype'

We could have even handle_log or something function which is tied to
sieve's logging.

By there mod_handleX gets username and can lookup example user's own
settings for spam-module.

If this was too confusing, read abit apache's modules source and you'll
understand what I mean :-)

filter:mod_foo (available filters comes from AVAILABILITY or something)
and we don't have rule 'if it', we just process results in next rule (much
nicer) and we can process multiple modules output in same rule instead of
making zillion of rules per every mod_*.

> 1) The only two useful email classifier modules are spam and virus tests.
own vacation-module etc, pretty much everything you could write after
that. Hello ISP's.

> 2) The addition or removal of an email classifier should require a
>    recompile of the Sieve server.
>

DSO is answer to this (even if it is 'slower' than static compiled) but we
could choose either to compile static or dynamic ofcourse. So those who
don't want to recompile always would just use dso-support.

>
> 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.

Yes ofcourse, but user's own settings to that module would be controllable
in module-code.

> 2) There should be an abstraction filter for common stuff like spam
>    and virus checking where sysadmins can change the implementation.
>

Ofcourse people make plugins when proper support is available, see how
many modules apache has got ;)


> 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)
>

I see more than that what we could do with DSO-plugins.

> 'filter :module' idea.  I do have one other extension to

module :myspamtest I think is better.

then message would be re-written abit by 'myspamtest' and then:

if header :matches "Spam" "Yes"
{
 fileinto "Spam"
}

"if it" is kinda pervertic if I say ;)

We live in OO-world nowadays, we could say "if this" :-)

++Titus