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.