Dave Goodrich wrote:

Ken Jones wrote:

"Charles J. Boening" <[EMAIL PROTECTED]> said


I also think spamc options should be stored in the same place.

Currently the spamc options can be set on the configure line.
We thought that would be a good place since the spamc options
are site wide. I think all the user preference options are stored
in each user_prefs directory.

So you would have one set of args to spamc? Something like

/usr/local/bin/spamc -s 25000 -f -d -p 1783 -u [EMAIL PROTECTED]

This is how we currently do it, with the users prefs stored in SQL so users can adjust their own score, set whitelists and blacklists, etc.

vdelivermail would call spamc. Personally, I don't think we should offer the ability to call
Spamassassin directly. It's just not as efficient.

I think when people talked about calling spamassassin they
meant calling spamc to talk to spamassassin. At least, that's
how the development code works now.

Maybe the spamc functionality could be compiled right into vdelivermail so no forking is
necessary. That would be slick!

Depends on how much of a moving target spamc code is. If it just
is a socket write/read type of thing then it might be a good idea.
Anyone feel like reviewing spamc.c?

spamc has been pretty stable since 2.63. I've run spamc on my toasters unchanged after two upgrades to spamd on my backend without a problem.
spamc has the option of using tcp instead of sockets. This was our choice as it allows connecting to either a local spamd or a remote spamd.

If I knew C better I'd review it, but I wouldn't trust my judgment. I can see where having spamc built in would be nice, but it could get complicated quickly. I'm moving more in favor of just letting vdelivermail check for spam headers and deliver appropriately.

Given a conf line in the domain limits file you could set what spam headers to look for. (This would allow for changes to SpamAssassin's header format. The headers have changed, and many people customise them, *they* would be your moving target.) By making the spam headers a user definable string, you also allow spam tools other than SpamAssassin to be used.

The more I think about this the more I like it. By limiting vdelivermail to only filtering on delivery, and allowing a user defined string in the domain limits file, there are many possibilities. Using a simple "string" equals action format you could filter as such,

# spam caught by MailScanner on a mail gateway
"X-TLS.net-MailScanner-SpamCheck: spam" .SPAM

# spam caught by spamc on a local machine
"X-Spam-Status: yes" .SPAM

# virus caught by MailScanner on a AV gateway
"X-TLS.net-MailScanner: Infected" [EMAIL PROTECTED]

Call what ever spam filter you like in your dot-qmail file, or using a smtp level scanner like qscan, or even having the scanning happen on another server altogether. As long as you can define what the headers will look like you can filter/forward as you like.


Dave Goodrich
Systems Administrator
Get rid of Unwanted Emails...get TLS Spam Blocker!

Reply via email to