>> This would handle both >> the problem of if the user wants their mail scanned and the disposition >> of the scanned mail. > Yep.
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: http://wiki.apache.org/spamassassin/UsingSQL >> 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 though... > New configure options? > --enable-spamassassin > 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? -Bill ***************************** Waveform Technology UNIX Systems Administrator
