PureMessage for Unix: Addressing a load increase due to increased spam volume.

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 (version 5.4.3+), PureMessage's MTA-level IP blocking capabilities have been expanded to 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 expensive 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 pmx 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. This 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:

http://www.sophos.com/support/knowledgebase/article/35003.html

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:

http://www.sophos.com/support/knowledgebase/article/22823.html

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

http://www.sophos.com/support/knowledgebase/article/35791.html

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:

     /opt/pmx/etc/enduser/enduser_ui.conf

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