[TriLUG] SpamAssassin as a daemon

[Jeremy Portzer]

On Fri, 2004-07-16 at 09:00, Brian Henning wrote:
> Hi Folks,
>   This is probably something I should just google, but I'm at work so I need
> to look busier than "surfing the web"..  (You know...doesn't matter what
> you're looking at; if you're not typing, you don't look busy...)  So I
> figured if anyone felt like pointing me to a howto, or explaining in brief,
> I'd ask how to take advantage of the daemon portion of SpamAssassin.  So far
> in my experience with spamassassin, I've used it as part of a procmail
> filter recipe (which doesn't seem to make use of spamd to me).  What does
> the daemon give me, and why is it better (or simply is it better) than the
> procmail filter method?  Further, if I want to have a non-sa-processed copy
> of all mail messages, does that preclude using spamd?
> 

Let's clarify a little bit of how spamassassin can work, as you're
mixing a couple of things.

First, spamassassin is primarily designed as a mail filter, a program
that takes e-mail messages on standard input, scans them and adds
headers and so forth, and then outputs them on standard output. A
standard way of invoking spamassassin is through the local delivery
agent, commonly procmail.   This can be done through the system-wide
/etc/procmailrc file, which means that all mail delivered locally is run
through Spamassassin, or via users' ~/.procmailrc files.

Another way to install spamassassin is within the mail server directly. 
For this, you need add-on programs like sendmail's "milter" interface, a
scanning framework like amavisd, etc.  This type of solution allows you
to filter mail that doesn't get delivered locally, e.g., you could build
a spamassassin gateway for your Windows mail server if you wanted. 
Jason Tower has talked about this setup quite a bit on this list if you
search the archives.

Now that we've got those two ways of using spamassassin covered, we can
discuss the several spamassassin binaries, "spamassassin", "spamc" (spam
client), and "spamd" (spam daemon).  When using the first method
outlined above, where spamassassin is called from Procmail, the easiest
way to run things is to put this in your ~/.procmailrc :
	:0fw
	| /usr/bin/spamassassin

This means that every time a message is delivered by procmail, this
binary is started up, the message is parsed, and then the binary shuts
down.  This is okay for a low-traffic system, but spamassassin consists
of a LOT of Perl code, a lot of text pattern matching, etc, and loading
all this code every time is a lot of extra overhead.  Consider that it
may be running many times simultaneously if a lot of e-mail is coming
in.

So, the developers invented the spamc/spamd combination.  In order to
reduce the processing time for each message, much of the spamassassin
code is kept loaded in memory at all times, through the spamd binary. 
Then, the spamc binary is the "client" used to connect to spamd.  But
this isn't a daemon like httpd or ftp that provides services to other
computers on your network, it's simply an internal thing that makes
spamassassin run better.  When you use spamc/spamd, you instead put the
following in your ~/.procmailrc :
	:0fw
	| /usr/bin/spamc
AND you make sure the spamd daemon is running in the background (perhaps
with "service spamd start" if you have it setup in the RC scripts).

So, when a message comes in, the spamc binary starts up, then contacts
the running spamd.  Spamd receives the messages, parses and processes
it, and then hands it back to this instance of spamc.  Spamc returns it
to procmail, and shuts down.  But since spamc is a very small program
written in C, the overhead of its startup/shutdown is not very high. 
The spamc/spamd combination is therefore much faster than running the
/usr/bin/spamassassin binary, but there is little functional
difference.[1]

Hope this helps, and sorry for being a little long-winded.  Please let
me know if you have further questions!

Jeremy Portzer

[1]  There are some small security configuration issues that are
different when using spamc/spamd.  See the "README.spamd" in your
spamassassin documention.

-- 
/---------------------------------------------------------------------\
| Jeremy Portzer        jeremyp at pobox.com      trilug.org/~jeremy     |
| GPG Fingerprint: 712D 77C7 AB2D 2130 989F  E135 6F9F F7BC CC1A 7B92 |
\---------------------------------------------------------------------/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://www.trilug.org/pipermail/trilug/attachments/20040716/7a900777/attachment.pgp>