Question about Sieve and "filters"

[Michael Fair]

> Yes agreed,
>
> I tried to hint about this while ago (see sieve & spamassassin) and Rob
> said there was no proper plugin-support, it would need
> COMPATIBILITY or SUPPORTED-things from timseved in login if there is not
> sa supported or not and such things so it would be pretty complicated or
not.

Well I think I've definitely come to the conclusion that
if it's complicated then it won't get implemented. :)
The question is can we make it simple enough to be both
implementable and useful but no simpler. ;)


> > This would be a simple command, like:
> > filter :spamassassin
> >
> > This command would take the email, shove it through
> > the "spamassassin" filter on standard in and read
> > the email back from standard out.  On any kind of
> > execution failure it would treat the filter as a
> > noop and use the email as it was prior to injection.
> >
>
> I hate fork() and system() (not re-usable) .. maybe if it could go via
> LMTP-socket or somekind (LMTP.. I don't think so).. example we could have
> sieve.conf and filters-section where you could specify filter-destinations
> (but then reply would need lmtp-connection back to sieve which makes it
"glue")..
> urgh, what about apache-module-like system which works like shine?
>
> .</------------
>
> start_module preload everything ..
> handlerX give msgreference in, return things..
> end_module shutdown loaded things if needed (cleanup)..
>
> ----------/>.
>
> loadmodule mod_spamassassin
> <ifmodule spamassassin>
>  <..>..</..>
> </ifmodule>
>
> Confusing?! :-)

Not too confusing.
I have two kinds of answers here.  Both are driven from
actually having something working instead of just designed
to perfection.

First, if fork and system aren't your thing, but that's
what it takes to get something going, then simply don't
use the filters and you can keep all the performance. ;)

Second, I totally agree with you that some other mechanism
apart from fork/system would be preferred.  Though I'm 90%
certain the first example filters should be one that calls
a shell script or something like "spamc" to fire the data
though a long running daemon program.

I have no real preference for what kind of module system
gets used and figured that the Sieve maintainers would
probably have a mechanism that would be acceptable to them.
I'm hoping they'll chime in with a vote or three.

Any sort of performance optimization would be most welcome,
but at the moment I'd just be satisfied with a minimal
functional spec that isn't too difficult to code up and
can be done as a relatively small patch that the maintainers
would accept.

-- Michael --