on 21:20 Thu 03 Feb, Alexander Dalloz (ad+lists at uni-x.org) 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