Re: [vchkpw] spamassassin development was spamassassin configuration
Dave Goodrich wrote: Ken Jones wrote: "Charles J. Boening" <[EMAIL PROTECTED]> said 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. So you would have one set of args to spamc? Something like /usr/local/bin/spamc -s 25000 -f -d 10.0.240.253 -p 1783 -u [EMAIL PROTECTED] This is how we currently do it, with the users prefs stored in SQL so users can adjust their own score, set whitelists and blacklists, etc. vdelivermail would call spamc. Personally, I don't think we should offer the ability to call Spamassassin directly. It's just not as efficient. I think when people talked about calling spamassassin they meant calling spamc to talk to spamassassin. At least, that's how the development code works now. 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? spamc has been pretty stable since 2.63. I've run spamc on my toasters unchanged after two upgrades to spamd on my backend without a problem. spamc has the option of using tcp instead of sockets. This was our choice as it allows connecting to either a local spamd or a remote spamd. If I knew C better I'd review it, but I wouldn't trust my judgment. I can see where having spamc built in would be nice, but it could get complicated quickly. I'm moving more in favor of just letting vdelivermail check for spam headers and deliver appropriately. Given a conf line in the domain limits file you could set what spam headers to look for. (This would allow for changes to SpamAssassin's header format. The headers have changed, and many people customise them, *they* would be your moving target.) By making the spam headers a user definable string, you also allow spam tools other than SpamAssassin to be used. The more I think about this the more I like it. By limiting vdelivermail to only filtering on delivery, and allowing a user defined string in the domain limits file, there are many possibilities. Using a simple "string" equals action format you could filter as such, # spam caught by MailScanner on a mail gateway "X-TLS.net-MailScanner-SpamCheck: spam" .SPAM # spam caught by spamc on a local machine "X-Spam-Status: yes" .SPAM # virus caught by MailScanner on a AV gateway "X-TLS.net-MailScanner: Infected" [EMAIL PROTECTED] Call what ever spam filter you like in your dot-qmail file, or using a smtp level scanner like qscan, or even having the scanning happen on another server altogether. As long as you can define what the headers will look like you can filter/forward as you like. DAve -- Dave Goodrich Systems Administrator http://www.tls.net Get rid of Unwanted Emails...get TLS Spam Blocker!
RE: [vchkpw] spamassassin development was spamassassin configuration
> > vdelivermail would call spamc. > > Personally, I don't think we should offer the ability to call > > Spamassassin directly. It's just not as efficient. > I think when people talked about calling spamassassin they > meant calling spamc to talk to spamassassin. At least, that's > how the development code works now. If it can be done, I'd say put the spamc options as a line in the domainlimits file. It would be more flexible that way. That way it's domain specific and not system specific. Charlie > -Original Message- > From: Ken Jones [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 03, 2005 7:19 AM > To: vchkpw@inter7.com > Subject: [vchkpw] spamassassin development was spamassassin > configuration > > > "Charles J. Boening" <[EMAIL PROTECTED]> said So let me see if I can > > summarize where this might be going. A lot has been talked > about on > > this topic. > > > > Use the pw_uid/pw_gid to check and see if a user wants their mail > > filtered. I'd also suggest setting another bit for > delivery. So we'd > > have a bit that says scan for spam > That code is already in the development branch and well tested. > > > and a bit that says deliver to domain default spam folder (.SPAM or > > whatever) or not. > Sounds good. > > > This would handle both > > the problem of if the user wants their mail scanned and the > > disposition of the scanned mail. > Yep. > > > The user's only options for tagged spam are to > > deliver to inbox so they can filter or deliver to a > predetermined spam > > container that the domain administrator specifies. > I agree. > > > vdelivermail would pull the delivery location for spam from > it's command > > line or from the domain limits file. > I'd rather put it in the domain limits file. Either option > would effect an > entire domain and we already have the domain limits method. > It's a good > place to add new options. > > > 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. > > > vdelivermail would call spamc. > > Personally, I don't think we should offer the ability to call > > Spamassassin directly. It's just not as efficient. > I think when people talked about calling spamassassin they > meant calling spamc to talk to spamassassin. At least, that's > how the development code works now. > > > 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? > > > Sound about right? Have I missed anything? > Nice summary! > > New configure options? > --enable-spamassassin > enables both spamc and spamfolder processing > this is already in the development branch > > --enable-spamdir = "relative directory for spam folder" > to override the default spam directory location > > Ken Jones > >
Re: [vchkpw] spamassassin development was spamassassin configuration
Ken Jones wrote: "Charles J. Boening" <[EMAIL PROTECTED]> said 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. So you would have one set of args to spamc? Something like /usr/local/bin/spamc -s 25000 -f -d 10.0.240.253 -p 1783 -u [EMAIL PROTECTED] This is how we currently do it, with the users prefs stored in SQL so users can adjust their own score, set whitelists and blacklists, etc. vdelivermail would call spamc. Personally, I don't think we should offer the ability to call Spamassassin directly. It's just not as efficient. I think when people talked about calling spamassassin they meant calling spamc to talk to spamassassin. At least, that's how the development code works now. 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? spamc has been pretty stable since 2.63. I've run spamc on my toasters unchanged after two upgrades to spamd on my backend without a problem. spamc has the option of using tcp instead of sockets. This was our choice as it allows connecting to either a local spamd or a remote spamd. If I knew C better I'd review it, but I wouldn't trust my judgment. I can see where having spamc built in would be nice, but it could get complicated quickly. I'm moving more in favor of just letting vdelivermail check for spam headers and deliver appropriately. Given a conf line in the domain limits file you could set what spam headers to look for. (This would allow for changes to SpamAssassin's header format. The headers have changed, and many people customise them, *they* would be your moving target.) By making the spam headers a user definable string, you also allow spam tools other than SpamAssassin to be used. DAve -- Dave Goodrich Systems Administrator http://www.tls.net Get rid of Unwanted Emails...get TLS Spam Blocker!
Re: [vchkpw] spamassassin development was spamassassin configuration
>> 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
[vchkpw] spamassassin development was spamassassin configuration
> "Charles J. Boening" <[EMAIL PROTECTED]> said > So let me see if I can summarize where this might be going. A lot has > been talked about on this topic. > > Use the pw_uid/pw_gid to check and see if a user wants their mail > filtered. I'd also suggest setting another bit for delivery. So we'd > have a bit that says scan for spam That code is already in the development branch and well tested. > and a bit that says deliver to domain > default spam folder (.SPAM or whatever) or not. Sounds good. > This would handle both > the problem of if the user wants their mail scanned and the disposition > of the scanned mail. Yep. > The user's only options for tagged spam are to > deliver to inbox so they can filter or deliver to a predetermined spam > container that the domain administrator specifies. I agree. > vdelivermail would pull the delivery location for spam from it's command > line or from the domain limits file. I'd rather put it in the domain limits file. Either option would effect an entire domain and we already have the domain limits method. It's a good place to add new options. > 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. > vdelivermail would call spamc. > Personally, I don't think we should offer the ability to call > Spamassassin directly. It's just not as efficient. I think when people talked about calling spamassassin they meant calling spamc to talk to spamassassin. At least, that's how the development code works now. > 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? > Sound about right? Have I missed anything? Nice summary! New configure options? --enable-spamassassin enables both spamc and spamfolder processing this is already in the development branch --enable-spamdir = "relative directory for spam folder" to override the default spam directory location Ken Jones
