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
