Johannes Berg wrote:
On Sun, 2007-09-30 at 10:57 +0200, Lars Stavholm wrote:
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?
Why what? Why logging at all? This was part of the "scaling better" plan. Why using dict service? Because it has good fallover behaviour etc.
I see.
- port to dovecot 1.1 Easy enough, you'll nail this one in minutes.
I'm just doing a proper build system etc. I'll get around to it :)
- give --user option to dspam (when no user in sig) This is needed for TrainPristine=on as well.
Right. Haven't thought about pristine training much yet, I still hope you'll nail your bug and get rid of that requirement ;)
Well, it would seem I've nailed it. However, when using the dspam group feature, there are configurations when the TrainPristine=on is useful, so I'm still thinking about keeping that requirement.
- ...
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.
Actually, I just realised that it's possible to give multiple options, maybe that's preferable?
It's possible, the expire plugin uses that mechanism.
plugin { dspam_trashes = trash1,trash2,trash3 dspam_options = --user=xxx --a --b --c --d ... }
Donno, matter of taste, or is it even a bit more user friendly.
Didn't quite get that one: what do you mean by "backend"? Part of dspam.c I assume?
Right now I'm thinking to build the plugin from multiple files depending on the backend selection. I'll publish the git tree this afternoon to show you, right now I have to go have a shower :)
I see.
I think I'll start from the git tree somebody else published. Sounds promising.
Decided to do my own because that one had libdspam integrated already. That's another backend then.
Good Luck and thanks for your help /Lars