Using spamd instead of Perl module (was RE: [Mimedefang] Bayes locking)

[Matthew.van.Eerde at hbinc.com]

David F. Skoll wrote:
> On Wed, 6 Oct 2004 Matthew.van.Eerde at hbinc.com wrote:
> This might be a good idea.  I wouldn't fork/exec spamc, but rather implement
> the SA client-server protocol directly in Perl (I don't think it's
> all that complex.)  Now that spamd has a preforked model, it
> might work quite well.
A rewrite of spamc in perl... I like it :)
Maybe a perl rewrite of clamdscan as well?  Here's a haiku...

MIMEDefang dot sock
spamd and clamd dot sock
Manage their own threads

>> It would interest me to see some real-world statistics on what
>> percentage of the time a given MIMEDefang slave spends in:
> 
> I have statistics for CanIt, and I can tell you that over 90% of the average
> slave's busy time is spent inside SpamAssassin (or in our case, doing
> DB queries.)  This is pretty consistent over hundreds of customers.
Ahhh... so it's moot in the real world.

I wonder if it might pay off during a virus storm though.  Without the SpamAssassin overhead, MX_MAXIMUM could be set nice and high... message_contains_virus() to beat back the storm.  On the otherhand, with MX_MAXIMUM stuck at (RAM / size of SpamAssassin), a virus storm might slow the server down enough to hold up legitimate mail.

spamd would have to be limited to a certain number of threads, of course... and the interplay of (maximum spamd threads vs. MIMEDefang threads) could get complicated.

Matthew.van.Eerde at hbinc.com                      805.964.4554 x902
Hispanic Business Inc./HireDiversity.com         Software Engineer
perl -e"map{y/a-z/l-za-k/;print}shift" "Jjhi pcdiwtg Ptga wprztg,"