on 21:20 Thu 03 Feb, Alexander Dalloz (ad+lists@xxxxxxxxx) wrote:
> Am 03.02.2011 17:33, schrieb Robert Heller:
>
> > Create a file named .procmailrc, that looks something like this:
>
> [ ... ]
>
> > :0fw
> > | /usr/bin/spamassassin -p /home/rtspam/.spamassassin/user_prefs
>
> It is the worst solution to spawn a new spamassassin process with each
> mail going through the filter. The consequences depend on the amount of
> mails transported and the powers of the host, but doing this with a
> resource hungry and slow process like spamassassin is not recommended in
> any way.
It'd be helpful to mention the alternative:
1: Run spamassassin in daemon mode.
2: Invoke the spamc client (should be installed with spamassassin though
I haven't confirmed for CentOS) in your procmail (or other mail
filtering) systems.
If you're running your own MTA locally or remotely, most have hooks
which allow for automated spam rejection based on rules or filters as
well. Discussion of that is beyond the scope of this list, but
texts/documentation for postfix, exim4, smail, and sendmail should all
address this adequately.
MTA spam filtering, done at SMTP transaction time, can be _very_
efficient and effective. It also has the added benefit, if done
correctly, of indicating to the sender what's happened (e.g.: mail was
rejected as spam), which in the case of false-positive rejections may
(assuming a clueful user, unfortunately not valid in many instances) be
helpful in identifying and correcting such instances.
--
Dr. Ed Morbius
Chief Scientist
Krell Power Systems Unlimited
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
