Version 5.4.3 Release Notes

Release Date: July, 2008

Improvements (5.4.3)

Proactive Botnet Detection with the MTA IP Blocker

Important: Whether you choose to block IP addresses using the PureMessage policy or by enabling MTA-level IP blocking, PureMessage now requires that the IP Blocker Service be enabled. This service is enabled by default. Additionally, if you opt to block IP addresses using only the PureMessage policy, you should still take note of the functionality described below. Enabling these features via the blocklist.conf file will cause the additional tests to occur earlier in policy processing, thus improving efficiency.

As part of the Sophos Sender Genotype, 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.

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.

These extended detection features are disabled by default. They can be enabled via the blocklist.conf configuration file in /opt/pmx/etc/pmx.d.

The improved functionality allows you to:

reject connections from dynamic hosts, even from new or unknown IP addresses that have not previously sent spam.
add custom IP addresses and fully qualified hostnames by using inclusion and exclusion lists to override entries supplied by SophosLabs. Both the IP Blocking Exception List and the IP Blocking Inclusion list must be manually added to a publication in order for these list to be distributed to edge servers in a multi-server configuration.
point rejected senders to a Sophos web page that advises why a message was blocked, and, in certain cases, offers a means to request that the address be unblocked. You also have the option of creating custom rejection pages that can include a variety of template variables. See the blocklist.conf man page for more information.

Important:

If you are using PureMessage with an external installation of sendmail, you must have the newest version of the sockmap.m4 file, which is distributed as part of the sendmail version bundled with PureMessage.

In this release, the sockmap.m4 file has been altered to enable extended IP blocking in the form of reverse DNS checks. If you have an external sendmail installation that has been configured to work with PureMessage, you must retrieve the new version of the sockmap.m4 file and copy it to your existing sendmail installation.

To get the sockmap file from the sendmail version included with 5.4.3, follow the instructions (beginning with step 2) in the “Configuring IP Blocking (External Sendmail Version)” section of the Getting Started Guide.

Note: If you want to authenticate connections using SMTP-AUTH while MTA-level blocking is enabled, you must modify PureMessage Postfix. For instructions see Configuring SMTP Authentication with the MTA IP Blocker in the Sophos Knowledgebase. SMTP-AUTH is not supported for external Postfix installations nor for any type of sendmail installation.

For more about the new features, see “Enabling or Disabling MTA IP Blocking” in the Manager Reference and the blocklist.conf man page.

Other Improvements

If the PureMessage server that is running the Mail Transfer Agent role is not located at the outer edge of your network, you can now modify the Relay test (pmx_relay) so that it detects the first untrusted relay. This cannot be done in the PureMessage Policy Constructor. It must be specified directly in the Sieve code. For more information, see the pmx-policy man page. (SUG20315)
When configuring LDAP authentication and LDAP lists through the PureMessage Manager, LDAP passwords appeared as plain text. As an added level of security, these passwords are now masked in all instances. (DEF03325).

Resolved Issues (5.4.3)

The (pmx_forward) test, which previously only accepted single strings, now accepts string lists, making it possible to specify multiple, comma-separated addresses for a single pmx_forward test. Although this test also appears in the Policy Constructor as "Forward To," string lists can only be configured directly in the Sieve code. See the pmx-policy man page for more information. (DEF19159)