Version 5.4.2 Release Notes

Release Date: April, 2008

Improvements (5.4.2)

A new report, Rejected MTA Connections, is available via the Groups Web Interface. This report shows the number of connections rejected as a result of MTA-level IP blocking. (SUG10361)
A new column displaying the serial number for each PureMessage component has been added to the Licensed Components page of the Support tab. These numbers are helpful to Sophos support, in the event that you need assistance. (SUG10623)

Resolved Issues (5.4.2)

Due to a limitation in PureMessage, lists associated with Administrative Groups could not be automatically synchronized with the PostgreSQL database. This has been fixed, although some manual steps may be required if you are running the Groups Web Interface as part of a multi-server deployment.

If additional steps are necessary, a message to this effect will be displayed after you upgrade to version 5.4.2. Follow the on-screen instructions to resolve any differences between the versions of group list files stored in the database and the group list files stored on edge servers.

If you need to refer back to these instructions, they will also be saved in /opt/pmx/var/log/install_log. (DEF09637)
Message log actions introduced in version 5.4.0 required the file members-per-group.cdb to be present in /opt/pmx/etc/. The absence of this file caused mail to stop flowing. Now mail flow continues, regardless of whether the .cdb file is there. (DEF18634)
Running PureMessage's pmx-logsearch-index utility resulted in a segfault if an individual message had an unusually large number of recipients. While this no longer results in a segfault, messages with an excessive number of recipients are still not indexed by pmx-logsearch-index. (DEF18766)
Running the pmx-logsearch program could result in a "couldn't execute command" error message or an HTTP 500 error. This has been fixed. (DEF18225)
Customers using the Postfix mail transfer agent would sometimes see the error message “503 5.1.1 Error:nested MAIL command”, which caused valid messages to be bounced back to the sending address. This has been corrected. (DEF19282)
The pmx-logsearch-index background service was consuming an excessive amount of processing power due to a loop function that was continuously checking for new entries in the mail and message logs. This was most noticeable on systems with a large numbers of logs but without a constant mail flow.

Additionally, the index_expire_days setting in logsearch.conf had no effect, regardless of the number of days specified. As a result, log search data would accumulate until it reached the specified size limit. This service no longer uses too much processing power, and the log search indexes are expired every seven days by default. (DEF20234)
The pmx-logsearch utility would become disabled each time the message log was rotated. This has been fixed. (DEF17335)
Certain types of messages, including tempfailed messages, were not being removed from opt/pmx/var/qdir/tmp when the “Drop attachment” policy action was used, which occasionally resulted in excessive disk space consumption. PureMessage now removes these files when processing is complete. (DEF06684)
There was sometimes a difference in the total messages displayed in the Spam Range Volumes and Message Categorization reports for the same time period. This occurred because messages that PureMessage deemed to be 100% spam were not included in the Spam Range Volumes report. This has been fixed. (DEF09266)
The Queue Status report in the Groups Web Interface (only accessible to global administrators) displayed some invalid queue directories, which could be selected from a drop-down list on this report page. This report now shows only valid queue directories. (DEF17454)
If PureMessage had been configured to issue quarantine digests, notifications address mapping had been specified, and the consolidate option in pmx-qdigest.conf was set to merged, the digests would sometimes contain messages that were included in previous digests. This has been corrected. (DEF12270)
In cases where the message body or message headers are altered or removed during processing, PureMessage now assigns a new Message-ID header. This change was made to improve RFC compliance. (DEF19630)
Previously, if you were using PureMessage in conjunction with the Java System Messaging Server (JSMS) mail transfer agent, messages could become trapped in the JSMS mail queue, where JSMS would continue indefinitely in its attempt to resend the messages. This occurred in instances when the MTA was attempting to pass messages to the PureMessage milter and the milter was unresponsive. If this occurs now, JSMS will attempt to resend according to the intervals specified in the backoff setting of the imta.cnf configuration file in JSMS. (DEF17471)