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
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 sp
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 la
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 c
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 i
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
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
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 pro
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 confi
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
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
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
12 matches
Mail list logo
