Johannes Berg wrote:
On Sun, 2007-09-30 at 09:30 +0200, Lars Stavholm wrote:
Input Options
The plugin input options was easy, it seems that dovecot simply puts the options line into an env variable that can be read with the getenv() call, e.g.:
dovecot.conf: ... protocol imap { mail_plugins = dspam } plugin { # dspam path ':' spam folder ':' [no]signature ':' ignore dspam = /usr/sbin/dspam:Spam:signature:Trash }
...and in the dspam plugin code I simply parse the result from getenv("DSPAM") and there's the input options.
In a future version one might add the ability to ignore more than one folder.
Coming from this, I think there are multiple things we should do. Let me try to remember the feature requests I've seen over the past year :)
- signature logging instead of direct retraining (could use dovecot's dict service)
Why?
- port to dovecot 1.1
Easy enough, you'll nail this one in minutes.
- give --user option to dspam (when no user in sig)
This is needed for TrainPristine=on as well.
- ...
To do this, I'd suggest the following. This should work great since AFAIK dovecot allows % expansion in the plugin options.
- change the options like dovecot does with A=B:C=D:...
There's a good idea, conformity.
- introduce options:
- BINARY=/usr/bin/dspam
- SPAM=folder1 (parser should allow giving it multiple times, i.e. allow SPAM=folder1:SPAM=folder2:SPAM=folder3...)
- TRASH=trash1 (similar to SPAM)
- USER=%u (if given, --user is given to dspam command line)
- OPTION=--mode=teft (arbitrary options for BINARY, can give multiple)
- SIGNATURE=X-DSPAM-Signature (header line in which signature is) here, * options are unique to the direct-retraining approach.
- split off the "backend" into a separate file with some hooks that can be built as needed, introduce various backends:
- dict signature logger
- direct dspam caller
- ...
Didn't quite get that one: what do you mean by "backend"? Part of dspam.c I assume?
I think I'll start from the git tree somebody else published.
Sounds promising.
Cheers /Lars