Clearswift SECURE Email Gateway 4.2.1 ReadMe

On installing this upgrade, Clearswift SECURE Email Gateway is upgraded to version 4.2.1.

You can only install this upgrade if you are already running a version 4 release of the Gateway. If you have a version 3 Gateway installed, please install version 4.2 using the instructions provided in the 4.2 Installation & Getting Started Guide.

Download the Clearswift SECURE Email Gateway4.2 Installation & Getting Started Guide

The following new features have been added in this upgrade:

• Message processing resilience

  Previous versions of the Gateway offered less resilience when processing large, corrupt or badly-formed messages. These messages occupied message processing slaves for excessive periods of time, resulting in a sustained state of low activity while the Gateway attempted to process the messages.

  Message processing management has now been enhanced to ensure that not all message processing slaves can be blocked at once, and hence mail flow will continue. In normal day-to-day processing, this will not affect Gateway performance negatively in any way. However, when the Gateway receives many of these bad messages within a short space of time, it will no longer get into a stuck state and will continue to process other mail as expected.

• Support for TLS connections based on recipient of outbound messages

  It is now possible to create Mandatory TLS connections to email domains without having to define the IP address/host names of the recipient's mail relays. The Gateway “connection” is configured with the domain name of the mail recipient. When a message is to be delivered to that domain, the Gateway uses DNS to resolve the domain and tries to establish a secure connection to the MX hosts for that domain. If domain name matches the host names of the mail relays, then a TLS connection will be attempted.

  If the recipient uses a third party mail relay, such as Symantec.cloud or Office365, then the Sendmail TLS checks will fail due to the relay server names not matching the recipient domain name. In this case, by enabling Opportunistic TLS, the Gateway will make the connection. By changing the TLS settings for the connection to require forced encryption in both TLS Client and TLS server modes, the messages will only be delivered if you send them in an encrypted form.

• Classification of newsletters as spam

  This upgrade allows the classification of newsletters as spam. In previous versions, the Gateway did not classify newsletters as spam. However, you can now configure the Gateway in SpamLogic Settings to reclassify newsletters as either Suspected Junk Email or Confirmed Junk Email.

• Support for adding images and text to the Gateway login page

  This upgrade allows the addition of images such as corporate logos, and text such as legal disclaimers to the login page of your Gateway’s user interface. This can be configured in Gateway Branding which you can access from the System drop-down menu. Images can be added in either .gif, .jpg, .png or .bmp format. The text has a maximum size of 1024 characters.

• Missing Manager does not determine message senders from “Sender” header of email

  In previous versions of the Gateway, Missing Manager determined the sender of messages using the “From” header of an email, which is used to specify the author of a message. However, in the route management part of the policy, the Gateway determined the sender of messages using the “Sender” header, as this specifies the mailbox of the agent responsible for the actual transmission of the message. Missing Manager has now been brought into line with route management and will use the “Sender” header if it exists. If it does not exist, Missing Manager will use the “From” header as before.

  While the contents of the “Sender” and “From” fields are commonly identical, they will differ when messages are sent on behalf of someone else. The change in this release will ensure that when messages are sent on behalf of someone else, Missing Manager will check that the manager of the person responsible for sending the message is copied, not the manager of the person who the message is sent on behalf of.

Fixed issues

This update fixes the following issues:

• Spam detection improvements

  Spam detection rates have been improved following changes in a number of areas.

• Increased efficiency of Kaspersky Anti-Virus updates

  The retrieval of anti-virus definition updates for the Kaspersky Anti-Virus component has been improved, resulting in more up-to-date virus definitions and hence more accurate detection.

• Logjam vulnerability

  The Logjam vulnerability exploits a flaw in the TLS protocol by using a man-in-the-middle attack to downgrade TLS connections. This update eliminates the threat by generating 2048-bit Diffie-Hellman groups with primes generated uniquely for each Gateway.

• Message processing improvements

  Enhancements to the content engine have corrected various issues encountered while processing messages and attachments such as PDF, XLSX and DOCX.

• Message processing timeouts

  The Message Processing timeout value configured in Policy Engine Settings was not being enforced correctly. This has been resolved and message processing will no longer be allowed to proceed beyond the configured limit.

• Unable to configure upstream MTA if connection management is disabled

  Previously it was only possible to configure upstream MTAs in SpamLogic Settings if you enabled connection management. However, the spam detection component of the Gateway also needs to know about any upstream MTAs, therefore it is now possible to configure them even if the Gateway is configured not to perform connection management.

  Still need to set MTA - make sure people remember to set them in both cases.

  Note: We strongly recommend that you configure upstream MTAs regardless of whether or not the Gateway is configured to perform Connection Management in SpamLogic Settings.

• Alarms cannot be cleared

  Some of the alarms in the Gateway appeared repeatedly or could not be cleared, despite selecting the option to clear them. The handling of alarms has been improved and now allows for clarification and easier management of any that appear.

• Restricting UI Access also denied PMM access

  When configuring the Gateway to restrict access from a specified IP address to the web user interface, the Gateway also restricted access to PMM from the same IP address. This restriction has been removed and access to PMM will be allowed for those IP addresses.

• PMM does not work after restoring to a new Gateway

  Previously, if you restored a full Gateway backup to a newly installed Gateway, the PMM database replication would fail. This has been resolved and replication now completes as expected.