<?xml version="1.0" encoding="ISO-8859-1"?>

<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/"><channel>
<title>How I Block Spam</title>
<pubDate>Sat, 04 Nov 2006 10:58:56 -0500</pubDate>
<link>http://www.howiblockspam.com/</link>
<description>How I Block Spam</description>
<language>en-us</language>
<image>
 <title>How I Block Spam</title>
 <url>http://www.howiblockspam.com/images/logo.gif</url>
 <link>http://www.howiblockspam.com/</link>
</image>
<webMaster>shilo&#104;&#064;&#115;hanje.com</webMaster>
<item>
<title>Integrating SpamAssassin into hMailServer</title>
<link>http://www.howiblockspam.com/index.php?name=News&amp;file=article&amp;sid=2</link>
<description>This article explains how I integrated SpamAssassin into a very busy email,
  large scale email environment.&amp;nbsp;  If you are serious about filtering email
  without blocking legitimate email, then you should use SpamAsssassin.&amp;nbsp;  SpamAssassin
  scores email based on a variety of different methods.&amp;nbsp; SpamAssassin considers
  the results of realtime blocking lists, DCC, SPF, and many content scans.&amp;nbsp; Additionally,
  each user can set his or her own threshold.
The biggest obstacle to using SpamAssassin is performance.&amp;nbsp; It is not
  obvious as to how to get enough performance out of SpamAssassin to utilize
  it in a large scale effort.&amp;nbsp; When most admins first try using SpamAssassin,
  they install it onto the email server and then set up a script to launch SpamAssasin
  once for each email.&amp;nbsp; This accomplishes the scoring, but crushes the performance
  of the email server because there is a lot of overhead when starting Perl and
  SpamAssassin.
The next thing people try is to run SpamAssassin as a daemon.&amp;nbsp; This is
  where you hear the term SpamD.&amp;nbsp; SpamD loads once and then stays running.&amp;nbsp; Then
  you can use a much smaller program called SpamC to communicate with SpamD.&amp;nbsp;  SpamC
  is a client program that was written in C.&amp;nbsp; It is a reasonably efficient
  way to send a text file to SpamD and receive a text file back from SpamD.&amp;nbsp; This
  method is far better than launching SpamAssassin once per email.
Once an admin gets SpamD up and running, the next obvious thing to try is
  running SpamD on a separate server from the email server.&amp;nbsp; This reduces
  the load on the email server.&amp;nbsp;  With SpamD successfully running on a separate
  server, you can launch SpamC on the email server and have it talk to SpamD.&amp;nbsp; This
  is an excellent solution, because SpamC launches and execute quickly.&amp;nbsp; The
  CPU and memory intense scanning takes place in SpamD, and that does not drag
  down the performance of the email server once you place SpamD on a separate
  box.
Many admins will be content to stop here.&amp;nbsp; For most operations, this
  will offer enough performance.&amp;nbsp; But I suggest we take things a step further.&amp;nbsp;  There
  are two things we can do to improve performance and scalability even more.&amp;nbsp; The
  first thing we can do is set up a cluster of FreeBSD boxes running SpamD.&amp;nbsp; We
  can use an open source product like pfSense to handle the load balancing duties.&amp;nbsp;  This
  makes it feasible to have many inexpensive SpamD boxes running.
The other thing we can do is integrate the SpamC code into the email server
  so no external processes need to be launched.&amp;nbsp; Even though SpamC is lightweight
  and efficient code, there is still a performance penalty from launching a process
  every time an email is received.&amp;nbsp; I suggest using a COM object to handle
  the usual SpamC duties in process.&amp;nbsp; Then have the email server call the
  COM object instead of SpamC when parsing email.&amp;nbsp;  This avoids the need
  to launch a process for each email.&amp;nbsp; The net result is far better performance
  and drastically more scalability.&amp;nbsp; Feel free to download my SpamC COM
  object  and my Event Handler for hMailServer.</description>
<pubDate>Sat, 04 Nov 2006 10:58:56 -0500</pubDate>
</item>
<item>
<title>Baby and the Bathwater</title>
<link>http://www.howiblockspam.com/index.php?name=News&amp;file=article&amp;sid=1</link>
<description>A long time ago, baths equaled a big tub filled with hot water. The man of the house had the privilege of the nice clean water, then all the other sons and men, then the women and finally the children.  Last of all the babies. By then the water was so dirty you could actually lose someone in it.  Hence the saying, &quot;Don't throw the baby out with the bath water&quot;.  Clearly the phrase is meant as a joke, because I cannot imagine any mother would be careless enough to lose her baby no matter how dirty the water got.

These days we have a similar dirty water situation with our mailboxes.  I am referring to all of the spam and virus emails that try to fill your mailbox and your customers’ mailboxes everyday.  It is disgusting when you launch your favorite email client only to find that your mailbox is full of dozens or even hundreds of new spam messages.  Your first instinct is to immediately delete everything in your mailbox and impose even tighter spam filtering restriction on email coming into your email server(s).  Your reaction is understandable.  
</description>
<pubDate>Fri, 03 Nov 2006 12:29:31 -0500</pubDate>
</item>
</channel>
</rss>

