>> This would handle both
>> the problem of if the user wants their mail scanned and the disposition
>> of the scanned mail.
If using SQL settings for Spamassassin, the user could also whitelist all
senders to avoid spam processing.
>> I also think spamc options should
>> be stored in the same place.
> Currently the spamc options can be set on the configure line.
> We thought that would be a good place since the spamc options
> are site wide. I think all the user preference options are stored
> in each user_prefs directory.
User prefs can also be in SQL, which is more flexible for larger sites.
There's a lot of info on this here:
>> Maybe the spamc
>> functionality could be compiled right into vdelivermail so no forking is
>> necessary. That would be slick!
> Depends on how much of a moving target spamc code is. If it just
> is a socket write/read type of thing then it might be a good idea.
> Anyone feel like reviewing spamc.c?
My experience with Spamassassin is that it changes rather a lot. The last
time I upgraded it I had to rewrite a lot of the config due to changes in
syntax and directives. I'm not sure of the innards of the code itself
> New configure options?
> enables both spamc and spamfolder processing
> this is already in the development branch
I'd like to see the ability to enable spamfolder processing without
calling spamc directly, since we have front-end machines to offload the
spam processing and have a seperate server that handles delivery to the
individual maildirs. Were you planning on just filtering based on the
spam/ham output from spamc, or by using the headers spamassassin inserts
in the message, or maybe some combination?
UNIX Systems Administrator