PureMessage for UNIX: Addressing a load increase resulting from greater spam volume

  • Article ID: 36596
  • Updated: 14 Jul 2011

This article describes best practices for addressing a load increase that arises from greater spam volume.

Operating system:

What to do

To help manage problems arising from high load due to a spam volume increase, the following best practices are recommended:

1. Update to the latest version of PureMessage to ensure that you have the latest enhancements for mitigating spam volume.

2. Use the IP Blocker service at the MTA level or policy level. The IP blocker works at the MTA or policy level to reject incoming mail, based on the IP of the connecting relay. The data is compared against a list of verified IP addresses that is updated every five minutes. This can result in a large reduction in the mail that the mail filter has to process. The greatest performance gains are achieved with the IP Blocker at the MTA level.

Proactive botnet detection with the MTA IP Blocker

The majority of dynamic hosts that send spam belong to botnets, which are groups of zombie computers. Although PureMessage was already capable of detecting dynamic IP addresses, it can now be done at connection time, thereby reducing the number of messages that the PureMessage policy engine has to process.

As part of the Sophos Sender Genotype, PureMessage's MTA-level IP blocking capabilities can optionally include reverse DNS (RDNS) tests and checks against a list of known dynamic IP addresses. SophosLabs specifies hostname patterns to block connections attempted by machines with dynamically assigned IP addresses. For an explanation of SophosLabs IP address classifications, see http://sophos.com/security/ip-lookup.

If enabling MTA-level IP blocking is not an option, gains can also be achieved by configuring IP blocking in the PureMessage policy. It is important that these IP checks take place before any of the computationally intensive anti-spam checks in the policy. 

3. Implement, if possible, valid user verification at the MTA or policy level. At the policy level, this is typically accomplished with the tool pmx-ldap-sync. See the PureMessage documentation for more information.

Note: If done at the MTA level, points 2 and 3 will ensure that your systems will block as much Spam as possible utilizing lightweight processes rather then heavyweight milter processes.

4. If your organizational policies allow, consider discarding spam with probabilities of 95% or greater. This will reduce the amount of quarantined messages, which in turn reduces the amount of indexing, expiry, digest creation and overall load on the database.

5. If you are running sendmail as your MTA, ensure that you are using a back-end queue for your mail_sender.

Run the following command as the PureMessage user:

     pmx-config | grep mail_sender

The default results should be:

     mail_sender           = "smtp:localhost:10026"

This means the system is using the back-end queue, which allows PureMessage to send (through a different port) mail, digests, released quarantine messages, and incoming mail that was split due to multiple-recipient policies.  This lessens the demand on the resources used for incoming mail.

6. Tune your PostgreSQL database. See the instructions in this knowledgebase article:


7. Disable any reporting jobs that are not used. For example, if you have server monitoring software, you might want to turn off the OS health report. If you do not require quarantine searches by spam rule hit, disable rule hit indexing.  This feature can consume a significant percentage of the database size. Consider disabling the reports in the Manager interface completely, and use the reports found in the Groups Web Interface. For instructions, see this knowledgebase article:


8. If you suffer from frequent server load spikes and you are currently using sendmail, consider switching to Postfix as your MTA. Postfix queues incoming mail and processes it as resources become available.  This results in better performance under heavy mail load. For instructions, see this knowledgebase article:


9. Ensure that large lists (>10000 entries) and maps (>500 entries) are converted to CDB format rather than plain text. The pmx-makemap utility can be used to accomplish this.  Please contact Sophos support if you need assistance.

10. If you are using custom rules, try disabling them to see if this affects performance. Custom rules can be found in the PureMessage Server Group Manager -> Policy -> Anti-Spam Rules -> Feature Group : Site Features -> (Click Filter). Badly written regular expression rules can cause excessive load and processing times.

11. Ensure that all PureMessage log files are being rotated.  The file /opt/pmx/etc/logrotate.conf can be used to achieve this goal.

12. If you upgraded from a version prior to 5.2.1, change the End User Web Interface backend configuration to use the "direct" method. This can be done by editing the file:


The value:

     backend = direct

If this value is modified, run the following command as the pmx user:

     pmx-profile sync-to-db --resource=enduser_ui_config --force

Re-start the pmx-httpd service as the pmx user:

     pmx-httpd restart

If you need more information or guidance, then please contact technical support.

Rate this article

Very poor Excellent