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)
  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 

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.

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

Reply via email to