Re: [vchkpw] spam assassin enable/disable per domain flag
Ken Jones wrote: I was wondering where the best place to put a domain wide enable/disable flag for spamassassin would be. What do you folks think? The idea would be to have a file checked by vdelivermail. If spam assassin is enabled, vdelivermail calls spamc before dropping the email into the users Maildir. Then the setup would be backwardly compatible with current sites. And they could enable/disable spam assassin by just updating the configuration file. Instead of checking for a file, why not use the extra space in the vpopmail gecos fields to store spam settings for that user? I've already got a bunch of files hanging around in each home directory (hopefully less if this spamassassin integration works). Another thing to consider is where to put the spam. Some of our users like it to go to the Trash folder, some like it to go to the Spam folder. This should be customizable somehow for vdelivermail. Actually, now that I think about it, I probably wouldn't even use the vdelivermail integration for spamassassin. I already call a .qmail file to do all the maildrop filtering and everything that vdelivermail can't do, so there's no need to spawn another vdelivermail just to filter spam when I can call spamc from maildrop. I still think the setting should go in a gecos field though :) --Doug
Re: [vchkpw] spam assassin enable/disable per domain flag
On Wed, 2004-01-14 at 11:18, Doug Clements wrote: Ken Jones wrote: I was wondering where the best place to put a domain wide enable/disable flag for spamassassin would be. What do you folks think? The idea would be to have a file checked by vdelivermail. If spam assassin is enabled, vdelivermail calls spamc before dropping the email into the users Maildir. Then the setup would be backwardly compatible with current sites. And they could enable/disable spam assassin by just updating the configuration file. Instead of checking for a file, why not use the extra space in the vpopmail gecos fields to store spam settings for that user? This'd be awesome as a place to store the boolean controlling whether we call spam assassin or not. I've already got a bunch of files hanging around in each home directory (hopefully less if this spamassassin integration works). Another thing to consider is where to put the spam. Some of our users like it to go to the Trash folder, some like it to go to the Spam folder. This should be customizable somehow for vdelivermail. This makes more sense to use something like Maildrop for. Why reinvent the wheel when you can easily use Maildrop to check the spam status and then deliver where you want? Actually, now that I think about it, I probably wouldn't even use the vdelivermail integration for spamassassin. I already call a .qmail file to do all the maildrop filtering and everything that vdelivermail can't do, so there's no need to spawn another vdelivermail just to filter spam when I can call spamc from maildrop. I like being able to toggle spamassassin above maildrop, because calling maildrop is heavier than checking something you've already pulled from a database. I personally have users who have maildrop without spamassassin, spamassassin without maildrop, and both. This way I can call just those pieces I need. I still think the setting should go in a gecos field though :) --Doug Also, any idea how quickly we could see versions of this? I'm on the cusp of deploying a spamassassin integrated setup to my users, and this'd allow me to streamline it and make it more reliable, so I'd be very interested in helping make this work (either through testing or code or ideas or moral support or whatever). -- Nicholas harring [EMAIL PROTECTED] Webley Systems, Inc.
Re: [vchkpw] spam assassin enable/disable per domain flag
On Jan 14, 2004, at 10:26 AM, Nick Harring wrote: Instead of checking for a file, why not use the extra space in the vpopmail gecos fields to store spam settings for that user? This'd be awesome as a place to store the boolean controlling whether we call spam assassin or not. The GECOS field is currently used to store the user's real name. You could store the boolean as a flag in the pw_gid field though. -- Tom Collins - [EMAIL PROTECTED] QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/ Info on the Sniffter hand-held Network Tester: http://sniffter.com/
Re: [vchkpw] spam assassin enable/disable per domain flag
On Wednesday 14 January 2004 11:40 am, Tom Collins wrote: You could store the boolean as a flag in the pw_gid field though. Great idea Tom! Here are my proposed changes for vdelivermail: New and unused pw_gid bit for disable/enable spam filtering. #define NO_SPAM_FILTER 0x4000 Currently the last defined bit is QA_ADMIN 0x2000 If --enable-spamassassin=y on configure: bit 0 = spam assassin enabled (current default) bit 1 = spam assassin disabled So, if the system admin wants to enable spam assassin it will automatically be turned on for all current and new users. Then individual users could have it turned off. If --enable-spamassassin=no (default) bit is ignored. same as all current versions. Here is the proposed vdelivermail logic: 1) get the user record (as normal) 2) If --enable-spamassassin=y was set on configure and delivering to the users Maildir and the no_spam_filter flag is 0 (default) then: vfork spamc -f [EMAIL PROTECTED], setup the file descriptors to write to spamc and read it's output. write the email to spamc read spamc output and write into the normal email file. 3) continue processing as normal with spamd started with the -v option (vpopmail support) spamd will look in the vpopmail users directory for a .spamassassin directory for personalized settings, local.cf file. Qmailadmin and vqadmin can be modified to operate on this directory/file. This is specifically for sites where the user picks up email from their inbox and has their email client do the filtering. I think the current maildrop method would work best for IMAP sites that want the email delivered into a different folder. Timeframe: If this sounds reasonable I will look at implementing it over the weekend into vpopmail (cvs or patch). Then I'll look at vqadmin. qmailadmin will probably be the most work so we could do that afterwards. Ken Jones
Re: [vchkpw] spam assassin enable/disable per domain flag
At 09:40 AM 1/14/2004, Tom Collins wrote: On Jan 14, 2004, at 10:26 AM, Nick Harring wrote: Instead of checking for a file, why not use the extra space in the vpopmail gecos fields to store spam settings for that user? This'd be awesome as a place to store the boolean controlling whether we call spam assassin or not. The GECOS field is currently used to store the user's real name. You could store the boolean as a flag in the pw_gid field though. What's wrong with making another column in the table? Seems like some fields are doing double duty and that could lead to confusion during later development.
Re: [vchkpw] spam assassin enable/disable per domain flag
Ken Jones wrote: On Wednesday 14 January 2004 11:40 am, Tom Collins wrote: snip-- with spamd started with the -v option (vpopmail support) spamd will look in the vpopmail users directory for a .spamassassin directory for personalized settings, local.cf file. Qmailadmin and vqadmin can be modified to operate on this directory/file. This is specifically for sites where the user picks up email from their inbox and has their email client do the filtering. I think the current maildrop method would work best for IMAP sites that want the email delivered into a different folder. Hi, I can't speak for anyone else, but the 15 or 20 qmail/vpopmail servers that I've installed or manage all use MySQL preferences rather than .spamassassin/user_prefs flat files. Just something to keep in mind if you are adding per user pref options to qmailadmin, it would be nice to be able to disable (or update the mysql database, but I know that would add a lot of extra work) the user prefs option but still have the ability to turn on and off the actual scanning. Regards, Rick
Re: [vchkpw] spam assassin enable/disable per domain flag
At 11:06 AM 1/13/2004, Ken Jones wrote: The idea would be to have a file checked by vdelivermail. If spam assassin is enabled, vdelivermail calls spamc before dropping the email into the users Maildir. Then the setup would be backwardly compatible with current sites. And they could enable/disable spam assassin by just updating the configuration file. What I'd like to see with this is the ability to have either domain wide spam assassin settings or user specific spam assassin settings for the domain. I'm planning to host multiple virtual domains with Spam Assassin (mySQL Backend for configs) as an option, and having spamc called with the user name equal to the domain name would be great. I know some people would like a lower level approach so having vdelivermail have the option of passing no user name, the domain name as the user name, and the full email address as the user name would be helpful.
Re: [vchkpw] spam assassin enable/disable per domain flag
On Tuesday 13 January 2004 1:40 pm, Anthony Baratta wrote: At 11:06 AM 1/13/2004, Ken Jones wrote: The idea would be to have a file checked by vdelivermail. If spam assassin is enabled, vdelivermail calls spamc before dropping the email into the users Maildir. Then the setup would be backwardly compatible with current sites. And they could enable/disable spam assassin by just updating the configuration file. What I'd like to see with this is the ability to have either domain wide spam assassin settings or user specific spam assassin settings for the domain. I'm planning to host multiple virtual domains with Spam Assassin (mySQL Backend for configs) as an option, and having spamc called with the user name equal to the domain name would be great. I know some people would like a lower level approach so having vdelivermail have the option of passing no user name, the domain name as the user name, and the full email address as the user name would be helpful. Do you mean: 1) site wide configuration: call spamc with no -u option 2) domain: call spamc with -u domainname 3) user: spamc -u [EMAIL PROTECTED] I've got it running now with 1) and 3) but not sure if it can do 2). Ken
Re: [vchkpw] spam assassin enable/disable per domain flag
At 11:47 AM 1/13/2004, Ken Jones wrote: Do you mean: 1) site wide configuration: call spamc with no -u option 2) domain: call spamc with -u domainname 3) user: spamc -u [EMAIL PROTECTED] I've got it running now with 1) and 3) but not sure if it can do 2). Yes. I would assume that this is all configurable via your domain config mentioned earlier. e.g. I could compile vpopmail to use #1 unless overridden by the domain config. Or am I off the beaten path?? ;-) Option 2 would nice because many people like to have multiple aliases and not forcing a spam config for each of these users would be helpful - me thinks. Why is option 2 more difficult if you already know the full target email address?
Re: [vchkpw] spam assassin enable/disable per domain flag
I'm actually doing something like this already. We've patched vdelivermail to leave files in the user's Maildir/tmp if an environment variable is set. That variable is the name of a program to run with a set of arguments detailing the user, domain, size, and filename that we've stored. Said program runs persistently and inserts that data into a MySQL database. Asynchronously, another program reads from that database, determines the preferences associated with that user/domain (stored in the vpopmail db), and runs over the file sitting in Maildir/tmp with things as needed (spamassassin, Clam, etc...) (If the program fails or is unexecutable, we tempfail back.) If the file passes (tagged or not) we move it to the user's Maildir/new directory, otherwise send it to .Trash, delete, or whatever else, and update the SQL db as needed with the resolution. It works pretty well (or will, once we finish tweaking our DB schema for this latest revision). -JC At 11:40 AM 1/13/2004, you wrote: At 11:06 AM 1/13/2004, Ken Jones wrote: The idea would be to have a file checked by vdelivermail. If spam assassin is enabled, vdelivermail calls spamc before dropping the email into the users Maildir. Then the setup would be backwardly compatible with current sites. And they could enable/disable spam assassin by just updating the configuration file. What I'd like to see with this is the ability to have either domain wide spam assassin settings or user specific spam assassin settings for the domain. I'm planning to host multiple virtual domains with Spam Assassin (mySQL Backend for configs) as an option, and having spamc called with the user name equal to the domain name would be great. I know some people would like a lower level approach so having vdelivermail have the option of passing no user name, the domain name as the user name, and the full email address as the user name would be helpful.
Re: [vchkpw] spam assassin enable/disable per domain flag
On Tuesday 13 January 2004 02:47 pm, Ken Jones wrote: Do you mean: 1) site wide configuration: call spamc with no -u option 2) domain: call spamc with -u domainname 3) user: spamc -u [EMAIL PROTECTED] I've got it running now with 1) and 3) but not sure if it can do 2). If you're using mysql user prefs, I don't see why you couldn't do #2. the value of -u is just a key used to look up the prefs in the mysql database. At worse, do #2 with -u [EMAIL PROTECTED] Ken Dave
