...
- blacklist.cf (aka. sa-blacklist.cf)
- blacklist-uri.cf (aka. sa-blacklist-uri.cf)
- bigevil.cf
Avoid at all costs on a busy server. If you are using these rulesets, consider using http://wiki.apache.org/spamassassin/SURBL instead.They have been deprecated years ago, and should not be used.
Try running without custom rulesets, measure memory usage, and re-add them gradually. By doing this you can determine which rulesets are worth the memory/accuracy trade-off. Note also that old rulesets probably won't catch any spam anymore, so you may be adding load for no good reason. Only use rulesets that are current and updated.
Spamd
If you have enough load to run into memory problems, and you're not using spamd, MailScanner, Amavisd-new, Mimedefang or another system that keeps the Mail::SpamAssassin modules loaded persistently, then that should be your first priority.
...
| No Format |
|---|
:0fw: spamassassin.lock * < 300000512000 | spamc |
Very large mails
Spamassassin will attempt to scan anything you throw at it. However, the time taken to scan messages rises exponentially and memory usage rise with the message size. The best way to deal with this problem is to limit the size of messages that get scanned by SpamAssassin. Tests show that larger messages are overwhelmingly likely to be non-spam, given the economics of spamming.
For procmail, the following recipe works:
| No Format |
|---|
:0fw * < 300000512000 | spamc |
(The "* < 300000512000" line prevents messages over 300 KiB 512kB from being passed to SpamAssassin.)
If you're using spamd, you should be aware that spamc will only pass messages under 250k 512kB in size to spamd by default. This is a built-in limit that you can override using the "-s" option on the command-line. Refer to the spamc man page for more details.
Starting with SpamAssassin 3.4.3, it is much more safe to scan larger messages. New body_part_scan_size/rawbody_part_scan_size options limit scanned data size so CPU usage won't be affected much. In 2019, spam up to 5MB in size has been seen, so it is recommended to use a large limit. Note that larger messages use much more memory per children, parsing a 5MB message can currently use 200MB memory, and 20MB message over 600MB, so keep the limit sane.
Network tests
If your scan times are very high (greater than 10 seconds per message) and you have network tests enabled, there's a good chance you're running into latency issues caused by network slowness, as described in NetworkTestsLatency.
...
Consider turning off Razor, Pyzor, or DCC, if you have those enabled. They can be very slow at times, and will typically increase latency by a second or two in the best case. Note that these limitations are removed starting from SpamAssassin 4.0, which has razor_fork, pyzor_fork options for asynchronous operation, and also using dccifd will be asynchronous.
AWL
If you're doing the above and still running out of memory intermittently, check the size of your AWL databases. Version 3.0.3 fixes an AWL specific bug that can cause memory bloat from large AWL db files.
...