I've been following this the last couple days and figured I'd put my
If you're wanting Spamassassin to be called from vpopmail, how about
making it work per domain or per user like simscan does with it's
simcontrol file. Then it could be on a per domain basis so you don't
have to micromanage. Or if you're hosting multiple domains you could
enable or disable on a per domain basis. You could store a vpopcontrol
file in the ~vpopmail/domains/<domain> directory. Vdelivermail could
Another option would be to just have vpopmail do delivery only. Most of
us are either running qmail-scanner or simscan. I recently changed from
qmail-scanner to simscan myself. With qmail-scanner or simscan doing
Spamassassin, I think all you need is a program to handle the delivery.
Currently I have a "stock" mailfilter file called from .qmail for anyone
who wants spam filtering. I have a web interface for users to turn it
on and off. The web interface just sends an email to a special account
who's mailfilter copies the "stock" one and a .qmail file to the user's
I saw some discussion the other day about the pw_uid and pw_gid fields
in the vpopmail sql tables. I vote to use the unused one (pw_gid IIRC)
to store the spam setting. Say relative path to SPAM maildir. If the
value is there, then deliver accordingly. If not, deliver to standard
delivery location. Also, an environment variable should also be set so
maildir/procmail filters can access it as well.
On my system, my $HOME looks something like this:
| |-- .SPAM
| | |-- cur
| | |-- maildirfolder
| | |-- new
| | `-- tmp
I cut out the irrelevant stuff. For all my users using Spamassassin I
filter tagged spam to the .SPAM directory. This shows up right above
"Trash" in Squirrelmail. In my mailfilter script I also make sure that
the courierimapsubscribed file has the right info so the user can see
the directory. The maildir is created the first time the user gets a
Point is that everyone does it different and flexibility is a good
thing. IMHO, add the capability to vdelivermail to check the "pw_gid"
field or add another data field "pw_spam" and stay away from compiled
options. We're doing the database call anyway right?
If we're adding Spamassassin support why not add TMDA support as well.
:) Call the TMDA script passing it the email, check the return result
and decide to deliver or not. If not, then the user isn't authorized
via TMDA and a challenge was sent out.
Again, this type of thing should be relatively easy to add to
vdelivermail. At least the concept is easy. :) Again, we'd have to
have a pw_tmda or similar to check and see if we should attempt TMDA
delivery. If so, then check for the existence of $HOME/.tmda. If it's
not there then create it by calling vadduser-tmda or similar to create
the structure and put the right information in the files. Then call
tmda-filter and handle delivery based on the return code.
I've kind of strayed off the Spamassassin topic but I think something
like calling TMDA is more suited to be built into vdelivermail than
calling Spamassassin. Let simscan and qmail-scanner take care of
From: Bill Wichers [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 01, 2005 11:05 AM
Subject: RE: [vchkpw] Spamassin configuration
> Putting the spamc->spamd calls inside vpopmail makes sense to me.
> However then putting the logic that decides where to deliver the mail,
> and tying those to irrevocably together is what I'm asking not be
> I'm in the same load situation as you, my systems do a couple hundred
> thousand local deliveries a day, and invoking spamassassin rather than
> spamc is unthinkable. However the overhead to fork and exec procmail
No one has suggested non-modifiable behavior. I suggested maybe a
compile-time directive to either do or not-do the filtering, and others
suggested some kind of config file to hold the options (and presumably
configuration info for the options too). All the discussion about the
name of the maildir to use has implied a *default* of "spam", but even
worst case you could always just change that in the source.
Running spamc/spamd directly from vpopmail seems very, very scary to me.
We handle well over 1 million messages/day here and have several beefy
machines front-ending for our mail system that do all the filtering
(ClamAV and Spamassassin). Running Spamassassin on the vpopmail
mailstore box simply does not work from us (nowhere near enough CPU/RAM
resources on the one server). Spamassassin really *is* seperate from
vpopmail. The filtering function could be efficiently implemented in
vdelivermail since that process is already involved in the message
delivery, and it would be nice to not have to involve shell or perl
scripts to filter messages into mailboxes.
UNIX Systems Administrator