On 08/20/2014 07:40 PM, Ruben Safir wrote:
The last time I used spam assassign, aside from pegging my CPU, and creating a huge database file, it also took forever to train. Admitedly, this was a long time ago, but I used to recomend that spam assassign be put on its own machine back then.
I'm sorry if "it works for me" and "yes it used to be but we changed all that" and "that was then, this is now" all sound hokey, but the reality is that SpamAssassin of the now is PDQ. Earlier this year I set up a new 13.1 on a new 1T drive and the arrangement Carlos says is inefficient, the 'one at a time" fully interlocked. That is fetchmail -> procmail -> spamassassin -> procmail -> INBOX There were about 4 riles before procmail handed off to spamassassin and about 20 after. Originally I had all logging for everything turned on so I could make sure it was all operating correctly. I had procmail doing 'full' logging, whch is about three lines per message, and I had each rule issue a message saying that it had been invoked and whether or not it did its job. The output of that procmail trace went to a log file, and I ran 'tail -f' on that file to the console. What went by on the console was too fast for me to read in detail, somewhere around 20-30 lines per second. I did see that the invocation of spamassassin was there, it occupied a constant position in the vertical scrolling. Now this may not be fast by corporate standards and I agree with Carlos that the use of a MTA like postfix and doing queueing and letting spamassasin run in parallel (on a multi-core machine) is a good idea. But my point is that for a single user who handles only about 200-500 messages a day, this is no slouch. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org