The problem whereby client devices trying to connect to zimbra using non SSL POP3 connections has been fixed as of 10:25 GMT this morning. The issue affected only a small number of mailboxes.

Details

We are migrating to a new 64bit Zimbra platform to allow for future expansion and to keep in line with Zimbra's latest best practice guidelines. This migration involves moving mailboxes off of their 32bit host servers onto new 64bit replacements. So far, all but one of the mailbox servers have been fully and successfully migrated and we are 50% through the final server's mailboxes (many of these 50% were migrated over this last weekend). This final server, although configured to allow non SSL connections for POP3 had an unrelated LDAP attribute set in a way which meant that non SSL connections were effectively blocked. We have reversed this setting, restarted the services and can now confirm that as of 10:25 GMT this morning, clear text POP3 connections are being accepted without issue. Our apologies for any inconvenience this may have caused.

Summary of Protocols requiring SSL

POP3 - not required, but recommended
IMAP - SSL must be enabled
HTTP - Optional (may change in future - see below)
ActiveSync - Optional (may change in future - see below)

Future SSL related changes

We are planning to set our Zimbra platform to force SSL for HTTP and ActiveSync but further testing is required to ensure complete client compatibility and to assess the impact before we go ahead. We will issue a notification well in advance of any change to allow you time to inform your users.

On Saturday 25th April 2009 at 9am we will update the A host record of the primary unbranded Zimbra domain so that all incoming connections terminate at our Zimbra Proxy Cluster. The impact on end users should be zero, however, it is recommended that resellers read the details below to fully understand the background to this change.

Any resellers using their own URL, especially if they have created CNAME or Host records resolving to 217.154.106.217 should take note of the details below.

Details

[zimbra . protectedservice . net] will be changed to resolve to 217.154.106.232

Background Information

Currently, when users access their Zimbra mailbox, all connections are handled by Zimbra Proxy - a new fairly new feature of Zimbra which is able to route users to the actual server which hosts their mailbox. Any Zimbra mailbox server can provide proxy server duties and we have been using the Proxy feature on our production Zimbra platform in this way for nearly a month with great success. The change outlined above means that our primary domain will now resolve to our dedicated Zimbra Proxy cluster running on multiple servers configured for High Availability. This has also been in production for some weeks and we have performed various test migrations similar to what we will do on Saturday without any noticeable effect on users.

Proxied Protocols

Zimbra Proxy handles all Zimbra protocols except for XMPP (Jabber), therefore users who wish to make use of an external IM client (Adium/Pidgin etc) should work out the hostname of the server their mailbox is hosted on and use it as the server name in their IM client. It is possible to work out which server hosts a mailbox by viewing the email headers of a received email in the mailbox concerned (look for the received: header field - it will contain a server name similar to zimbra-mbox[X]....)

The problem reported a few minutes ago has been resolved and was due to an LDAP issue on one of our MX server clusters. Some mail handled by mx26 may be delayed whilst the remote servers retry delivery to us. Sorry for any inconvenience this may have caused.

We are investigating an issue with our external MX servers which may be affecting mail delivery