Sunday, March 20, 2011


UPDATE 3/21/2011: sa-update has disabled these problematic rules.
It seems some mail is triggering a rare bug in re2c (perl) that can cause spamassassin to get stuck in a 100% loop and cause significant problems for a server.  While this is a very serious problem, it affects only non-default configurations that use sa-compile.  Upstream is working on an emergency sa-update rule push to force disable.  Until then you can workaround this problem in two possible ways below.

Stop Using sa-compile
  1. Turn off whatever runs sa-compile.
  2. Delete /var/lib/spamassassin/<VERSION>
  3. sa-update
  4. Restart your spamd.
Continue using sa-compile, but Manually Disable some Rules
  1. Add these three lines to your
  2. sa-compile how you normally would do.
  3. Restart your spamd.
(I personally don't use sa-compile because this is not the first time it caused weird bugs, and its time savings seems to be insignificant compared to the delay of waiting for network queries.)


  1. Warren, what are the performance benefits of sa-compile? What is the memory/CPU overhead? I don't use it as well. Performance measurements would make for a good post.

  2. Julian, that is a good suggestion. I will consider investigating this sometime later for an article.
    Meanwhile check out this page. In most cases I think sa-compile simply isn't worthwhile because you are optimizing for the wrong problem. Your bottleneck is far more likely to be network or I/O. Given the stability risks of sa-compile I suspect you're better off not using it.