RE: Sendmail, MimeDefang Spamd ??

2005-03-22 Thread Matthew.van.Eerde
Matt Kettler wrote:
 Second, converting to spamc/spamd would be SLOWER for a MimeDefang
 setup, not faster.

eh... depends on what else MIMEDefang is doing...
 
 MimeDefang calls the SpamAssassin perl API's directly, a method that
 is faster than using spamc/spamd, but is only usable by tools written
 in perl. 
 
 spamc/spamd is faster than calling the spamassassin command-line
 script, but not faster than directly loading the API's.

SpamAssassin memory is frequently a bottleneck.

To use a military analogy:

MIMEDefang threads are like infantry.  SpamAssassin objects are like tanks.

I'm sure every infantryman would love to drive around their own tank.  But that 
would use a *lot* of gas.  The infantryman would say but this is faster.  But 
tell that to the supply sergeant who's trying to supply the division :)

Another option is to have the tanks nearby, in easy call range of the infantry 
squad.  Much of the time the infantry will be able to handle the enemy 
themselves.  When they need a tank, they can radio for one - they'll have to 
wait a bit, but the benefit is that you can have a LOT more infantry this way 
and still not run out of gas.

The MIMEDefang analogy of this is as follows:

A typical MIMEDefang setup might have ten MIMEDefang threads, each with its own 
SpamAssassin object.

Suppose you have a lot of custom-/third-party-code to deal with various kinds 
of bogeys.  You might reject email that fails a clamav scan, for example.  Or 
you might reject email that has a From: header of a nonexistent address at your 
domain (all of which can be done in MIMEDefang.)  In this sense the MIMEDefang 
thread is capable of eliminating the email itself, without an expensive 
SpamAssassin call.  Of ten SpamAssassin objects, maybe seven might be active at 
any given time.

Having a Perl implementation of spamc would allow this server to have seven 
spamd threads running.  In the space saved by the extra three idle 
SpamAssassin objects, you could run as many as a hundred MIMEDefang threads.  
This allows much more throughput, at the cost of any particular individual 
thread running a little slower.

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


RE: Sendmail, MimeDefang Spamd ??

2005-03-21 Thread Matthew.van.Eerde
Marcelo Maraboli wrote:
 Is Spamd supported by MimeDefang ??

No - MimeDefang is written in perl, so it just use's SpamAssassin in the Perl 
sense.

As an aside, it would be nice to have a SpamAssassin::Client perl module so 
that each MIMEDefang thread didn't have to carry around it's own SpamAssassin 
object.  This could also allow multiserver environments to run MIMEDefang on 
perimeter servers, each connecting to a central SpamAssassin server.

 should I use milter-spamc/0.25 (beta) instead ??

There are various things you can do to help MIMEDefang run faster - see 
mimedefang.org
Among them are -
* use the embedded perl interpreter
* run the temporary directory on a RAM disk

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


Re: Sendmail, MimeDefang Spamd ??

2005-03-21 Thread Matt Kettler
Marcelo Maraboli wrote:

 Hello

 I have Sendmail 8.12.11 + MimeDefang -2.40 running the
 perl version of SpamAssassin 2.63 and my CPU is at 98%,
 so I want to change to Spamd/Spamc, but I cannot find
 the exact install procedure...

 Is Spamd supported by MimeDefang ??  should I use
  milter-spamc/0.25 (beta) instead ??


First, I'd suggest upgrading to 2.64 or higher before going much
further. SA 2.63 is vulnerable to a DOS attack by messages with
specially malformed mime sections.

Do not run versions 2.50-2.63 on a production server due to the
potential for DoS.


Second, converting to spamc/spamd would be SLOWER for a MimeDefang
setup, not faster.

MimeDefang calls the SpamAssassin perl API's directly, a method that is
faster than using spamc/spamd, but is only usable by tools written in perl.

spamc/spamd is faster than calling the spamassassin command-line
script, but not faster than directly loading the API's.