Sieve is pretty cool, but it's just not enough for what I need. I want to
write my own Perl handler which would allow me to implement some stuff that
Sieve doesn't do:
- Site-wide filtering policy called first
- Checks against MAPS customisable per-user
- Scoring of potential spam based on header checks+MAPs+etc...
- Filtering to custom folders or bounce to sender based on score
- ...and a whole bunch more
So basically what I want to do is use the notify_unix hook to not only
notify, but also to tell Cyrus what to do with the message. Is there
currently any way for a notify hook to tell Cyrus to file a message into a
folder, or is there no communication back to Cyrus from the hook? In fact,
I'd like my hook to be able to tell Cyrus to do any of the actions supported
by Sieve--vacation message, fileinto, reject, ... What would be required to
get this to work? All I would need is for Cyrus to allow a hook like notify
does, but to allow the hook to return some kind of value telling Cyrus what
to do--then I could write the Unix socket function and Perl daemon as I did
with notify_unix.c.
Going further, it would be really nice to be able to hook into Cyrus at many
points, much like Apache supports hooking into anywhere in its process using
C modules or mod_perl. I'd like to be able, for instance, to customise the
authentication process, filtering process, socket closing process, etc... I
can already do bits of this (by using a custom pwcheck daemon I already
customise the authentication process) but it would be nicer if this was
available and consistent across all phases of a Cyrus session.
Anyone interested in helping to build something like this? I can do all the
Perl/daemon stuff, but I need a Cyrus/C guru to help build/extend the Cyrus
hooks. I don't think this is a big job--it's just a case of defining the API
and sticking calls to the hooks in the right places. Oh, and refactoring the
Sieve stuff a bit so rather than be a special case Sieve is just one user of
the generic API.
