Zimbra

Zimbra Desktop 2.0 Beta 4 has just been released. Zimbra Desktop is a free and open source email client application that gives you on- and off-line access to all your email accounts in one place. Whether you use Zimbra, Gmail, Yahoo! Mail or Microsoft Exchange, Zimbra Desktop greatly simplifies your inbox experience.

A detailed list of ZD 2.0 enhancements is available at the Zimbra Product Portal. If you are coming from an earlier ZD 2.0 Beta, one of the bigger differences you’ll notice is Zimlet support. We’ve included Zimlets like Email Reminder and everyone’s favorite Social. And you can install additional ZD compatible Zimlets via the Preferences area.

Download links are provided below. Please comment, submit feedback and questions via the Community Forums, or make use of Bugzilla to file confirmed bugs and request enhancements.

Enjoy!

Download Zimbra Desktop 2.0 Beta 4

• Windows: zdesktop_2_0_beta4_b10514_win32.msi (MD5)
• Mac OS: zdesktop_2_0_beta4_b10514_macos_intel.dmg (MD5)
• Linux: zdesktop_2_0_beta4_b10514_linux_i686.tgz (MD5)

Documentation

• Installation & Setup
• Release Notes
• FAQ

A common integration question we hear is how to handle “sign-on” between an external enterprise application and Zimbra? This scenario is when a user has signed-on to an enterprise application (for example, a Customer Relationship Management system) and that application needs to access data stored in the user mailbox hosted on a Zimbra server. To transition from the enterprise application to Zimbra, you could prompt the user to re-enter a username/password but that is not a very seamless experience. To automatically “sign-on” the user as they move between systems requires a trusted third party to “vouch for” or “assert” the user identity.

Zimbra includes a proprietary protocol for achieving this assertion, which is referred to as “Preauth“.  Preauth works by having a key that is shared between a third party application/system and Zimbra. The third party specifies the userid, a timestamp, optionally an expiration time, and an SHA-1 HMAC value computed over that data using the shared key. The Zimbra server, after successfully validating the HMAC value received in the request, redirects the user to the target Zimbra service.

There is also an alternative: SAML. SAML (Security Assertion Markup Language) can be thought of as a standard way of achieving what Zimbra Preauth protocol does.

SAML is a standard that defines an XML-based framework for exchange of security information between various business services (see http://saml.xml.org/saml-technical-overview). It is a widely adopted standard for Single Sign-On (SSO) and Federated Identity use cases. So one can envision that in scenarios such as above, a SAML assertion could be issued for the user by a central/trusted Identity Management System within the enterprise, and that assertion could be used to allow access to Zimbra. A SAML assertion typically contains security information about a subject/principal and could, for example, convey information like “This user is John Doe, he has an email address of john.doe@example.com, he was authenticated into this system using a password mechanism, at this time and date, etc”.

Example Zimbra SAML Interactions

SAML interactions/exchanges take place between entities referred to as the SAML asserting party and the SAML relying party. An asserting party is an entity that creates/issues SAML assertions. It is also sometimes called a SAML authority. A relying party is an entity that uses assertions it has received.

The picture below illustrates a setup where a user accesses a Zimbra service using a SAML assertion without any Zimbra-proprietary authentication token/cookie or Preauth. In this configuration, the Zimbra server acts as the SAML relying party.

Here’s a brief description of the interactions happening in this setup:

1. User authenticates and requests a SAML assertion from the SAML authority. [Note: This step happens outside Zimbra]
2. The SAML authority makes sure that the user has been authenticated (by some means) and then issues a SAML assertion for the user. [Note: This step happens outside Zimbra]
3. The user’s client sends a SOAP request containing an assertion identifier to the Zimbra server:

   <soap:Envelope xmlns:soap='http://www.w3.org/2003/05/soap-envelope'>
       <soap:Header>
           <context xmlns='urn:zimbra'>
               <authToken type='SAML_AUTH_PROVIDER'>b07b804c-7c29-ea16-7300-4f3d6f7928ac</authToken>
           </context>
       </soap:Header>
       <soap:Body>
           <SomeRequest xmlns='urn:zimbraMail'>…</SomeRequest>
       </soap:Body>
   </soap:Envelope>
   

   [Note: The client could have alternatively sent the SAML assertion itself inside the request. Also, we are designating the auth token type as SAML_AUTH_PROVIDER, which is a custom authentication provider you must create for your environment. Later in this blog, we describe how to use Zimbra Server Extensions to implement a custom SAML Auth Provider.]

4. Zimbra server calls the SAML Authority and inquires about the assertion by passing the identifier:

   <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
       <soap:Body>
           <samlp:AssertionIDRequest ID="id-1268148042731" Version="2.0" ... >
               <samlp:AssertionIDRef>b07b804c-7c29-ea16-7300-4f3d6f7928ac</samlp:AssertionIDRef>
           </samlp:AssertionIDRequest>
       </soap:Body>
   </soap:Envelope>
   

5. The SAML Authority trusts the Zimbra server (relying party) and looks up its store of issued assertions and responds with the assertion:

   <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
       <soap:Body>
           <samlp:Response ID="id-1268148042741" ... >
               <samlp:Status>
                   <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
               </samlp:Status>
               <saml:Assertion ID="b07b804c-7c29-ea16-7300-4f3d6f7928ac" ... >
                   <saml:Issuer>http://samlAuthority</saml:Issuer>
                   <saml:Subject>
                       <saml:NameID>user1@domain.com</saml:NameID>
                       <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:sender-vouches"/>
                   </saml:Subject>
                   <saml:Conditions NotBefore="2010-03-09T09:22:05Z" NotOnOrAfter="2020-12-05T09:27:05Z">
                       <saml:AudienceRestriction>
                           <saml:Audience>http://zimbra</saml:Audience>
                       </saml:AudienceRestriction>
                   </saml:Conditions>
                   <saml:AuthnStatement AuthnInstant="2010-03-09T09:22:00Z">
                       <saml:AuthnContext>
                       <saml:AuthnContextClassRef>...SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
                       </saml:AuthnContext>
                   </saml:AuthnStatement>
               </saml:Assertion>
           </samlp:Response>
       </soap:Body>
   </soap:Envelope>
   

6. Based on its trust on the SAML authority, the Zimbra server validates the SAML assertion and sends back a response to the client:

   <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
       <soap:Header>…</soap:Header>
       <soap:Body>
           <SomeResponse xmlns="urn:zimbraMail">…</SomeResponse>
       </soap:Body>
   </soap:Envelope>
   

Note: The sample messages shown above are very simplistic. In the real world, the message exchanges, especially those between the relying party and the SAML authority, are secured using TLS and/or message-level security mechanisms.

Implementing the SAML Auth Provider

The Zimbra server provides various extension points to allow extending the Zimbra server functionality (see Extending Zimbra with Server Extensions). One such extension point is the com.zimbra.cs.service.AuthProvider abstract class and an abstract sub-class the ZimbraAuthProvider. These classes know how to process/validate the Zimbra proprietary authentication tokens (or cookies).

To support SAML assertions (or tokens) within Zimbra, you can write a SamlAuthProvider class that extends AuthProvider:

public class SamlAuthProvider extends AuthProvider {

    protected SamlAuthProvider() {
        super("SAML_AUTH_PROVIDER");
    }

    protected AuthToken authToken(Element soapCtxt, Map engineCtxt) throws AuthProviderException, AuthTokenException {
        // Extract SAML assertion identifier from soap context
        // Call SAML authority and request for the SAML assertion corresponding to the identifier
        // Validate and return the SAML assertion (token)
    }
    ...
}

The SamlAuthProvider can be registered with the Zimbra server by doing the following inside the ZimbraExtension.init() method:

AuthProvider.register(new SamlAuthProvider());
AuthProvider.refresh();

Additionally, the  “zimbra_auth_provider” localconfig property needs to be modified (using the Zimbra Command Line Interface) to add your custom saml auth provider to the list of registered “zimbra auth providers”:

zmlocalconfig -e zimbra_auth_provider=SAML_AUTH_PROVIDER,Zimbra

As you can see, this is a powerful mechanism for extending Zimbra to support SAML and create a seamless Single-Sign-On experience. Although the AuthProvider class is not officially supported yet in a production environment yet, it is fine to use it in a proof of concept or an experimental project.

With over 55 million commercial Zimbra mailboxes deployed worldwide, and millions more on open source, there are many users reaping the benefits of our next-generation collaboration experience. Many factors contributed to our rapid adoption — such as integrated conversation views, tagging, sharing, powerful search, and mobility — but one of the most important is the ability to customize and extend Zimbra.

To promote extensibility, the Zimbra platform exposes powerful Theme, Data and Zimlet APIs. With these APIs, you can customize everything from branding and interface styles…to integrating external applications & services…to implementing new features. And with a vibrant Community continually using these technologies to enhance Zimbra, the customization you are looking for might already be available.

To that end, we have been busy at work leveraging new resources from our friends at VMware and are pleased to announce the new Zimbra Gallery as the destination for sharing Zimbra product extensions.

The new Gallery includes improved navigation and search capabilities so it is easier than ever to find extensions for Zimbra. The Gallery supports ratings and reviews so Community members can share their feedback and experiences. It is also much easier to share extensions, update status and highlight your work with improved extension “landing pages.”

Checkout the new Gallery at http://gallery.zimbra.com

The Gallery includes new Zimlets & Themes as well as some updated favorites such as Appointment Summary, Birthday Reminder, Email Attachment Alert, Email Downloader and Email Quotes.

Please visit the Gallery, download extensions, provide feedback and contribute. We look forward to seeing the library of available extensions in the Zimbra Gallery expand in the weeks and months to come. Enjoy!

Zimlets and the ability to extend the Zimbra Web Client is a pretty widely known capability. But did you know that Zimbra also has a framework that allows developers to extend Zimbra server-side functionality?

Zimbra Server Extensions provide a mechanism to add functionality to the server in lieu of modifying web.xml and other web server configuration files. By implementing a Server Extension, you can inject or in some cases, intercept, server-side functionality. Some examples include:

• Handling authentication requests against a user store different than the built-in Zimbra LDAP user store. Server Extensions provide a way to “plug-in” your custom authentication mechanism.
• Creating custom SOAP requests to augment the current Zimbra SOAP API.
• Registering custom mime handlers for the processing of message mime components (i.e. body, message and multipart nodes).
• Performing registration or “bootstrapping” of server-side components, such as the Microsoft Exchange Free/Busy resolver.

Getting Started

Writing an extension starts by implementing the com.zimbra.cs.extension.ZimbraExtension interface:

public interface ZimbraExtension {

    /**
     * Defines a name for the extension. It must be an identifier.
     * @return the extension name
     */
    public String getName();

    /**
     * Initializes the extension. Called when the extension is loaded.
     *
     * @throws ServiceException
     */
    public void init() throws ServiceException;

    /**
     * Terminates the extension. Called when the server is shut down.
     *
     */
    public void destroy();
}

To create your Extension:

1. Write a MyZimbraExtension class that implements the ZimbraExtension interface.
2. Create a JAR file (for example: myext.jar) and include the following attribute in the JAR manifest file:
   • Zimbra-Extension-Class: com.example.MyZimbraExtension
3. Place the myext.jar into the {zimbra_install-dir}/lib/ext/{my-ext-dir} directory.

Below are a few examples, though not an exhaustive list, of how the Server Extension framework can be used:

Custom HTTP Handlers

A Server Extension can process HTTP GET/POST/OPTIONS requests by extending the com.zimbra.cs.extension.ExtensionHttpHandler abstract class and registering the subclass in the Extension init() method.

public class MyHttpHandler implements ExtensionHttpHandler {

    // the path under which MyHandler is registered
    public String getPath() {
        return "/myext/myhandler";
    }

    // override doGet/doPost/ doOptions as needed
    ...
}

and in MyZimbraExtension.init(), do the following:

com.zimbra.cs.extension.ExtensionDispatcherServlet.register(this, new MyHttpHandler());

This would result in processing of requests at http://{my-zimbra-server-url}/service/extension/myext/myhandler being delegated to the MyHttpHandler class.

Custom SOAP Requests

If an Extension needs to support extra SOAP requests, it can do so by implementing the com.zimbra.soap.DocumentService interface and registering custom SOAP requests & operations handlers from it.

public class MyDocumentService implements DocumentService {

    /**
     * Registers <code>DocumentHandler<code> instance with document dispatcher.
     */
    public void registerHandlers(DocumentDispatcher dispatcher) {
        dispatcher.registerHandler(HelloWorldOp.REQUEST_QNAME, new HelloWorldOp());
    }
}

and in MyZimbraExtension.init(), do the following:

com.zimbra.soap.SoapServlet.addService("SoapServlet", new MyDocumentService());

Custom Authentication

If your Zimbra deployment needs to authenticate user passwords from, for example, a “home grown” authentication system and not from LDAP (which is the out-of-the-box Zimbra solution), the Extension can do so by extending the com.zimbra.cs.account.auth.ZimbraCustomAuth abstract class.  The subclass would have to implement an authenticate() method to which the plain-text password is passed as one of the arguments.

Learn More

A detailed implementation document is available at ZimbraServer/docs/extensions.txt. Now that we’ve introduced the topic, stay tuned for more information on specific Server Extension implementation examples. 

New with Zimbra Collaboration Suite 6.0 is the ability to create Zimlets that show-up as tab applications in the Zimbra Web Client.  This powerful new feature, unique to the Zimbra platform, enables partners & customers to more easily integrate third-party applications with the Zimbra Web Client. And there are already new Zimlets taking advantage of this feature, like the Social Zimlet or the BroadSoft Zimlet.

Let’s take a look at how to implement some of the basic operations of this new feature…But first, some background: the Zimbra Web Client displays multiple default applications across the top of the interface as “tabs”. These applications include (based on your deployment configuration): mail, address book, calendar, tasks, documents and briefcase. With the Zimlet Tab feature, you can add “tabs” to this array of applications.

Creating the Tab

It starts with creating the tab in your Zimlet JavaScript code. A createApp() method has been added to the ZmZimletBase class. Since all zimlets extend ZmZimletBase, to create a tab, all you need to do is call the this.createApp() method from your Zimlet. The three parameters to createApp() are:

• Tab label: the visible text “label” for the tab (for example, “My Tab”).
• Tab icon: the CSS class to use for the icon in the tab.
• Tab tool tip: the tab tool tip shown when hovering over the tab.

So creating a tab is as simple as calling the following from your Zimlet:

this._tabAppName = this.createApp("My Tab", "zimbraIcon", "A new tab app");

This method returns a unique application name for the newly created tab. You will need this unique name to manage and retrieve the different components of the tab, so it’s best to capture this return value.

Listening for Tab Application Events

Your Zimlet will also receive application events as tab applications are launched for the first time and as a user navigates around the Zimbra Web Client between tab applications. The events will be received in the ZmZimletBase.appActive() and ZmZimletBase.appLaunch() methods. By implementing these methods in your Zimlet, you will be able to know when a user launches and switches between tab applications.

Anatomy of a Tab Application

The layout of a tab application includes the following: the Tab and the Content Areas (i.e. Toolbar, Main and Overview).

The Tab

The row of tab applications across the top of the Zimbra Web Client interface is managed by an application chooser, which is represented by the Zimbra JavaScript class ZmAppChooser. The ZmAppChooser class extends ZmToolBar, making the row of tab applications basically a toolbar with buttons that look like “tabs”.

That means, after tab creation, you can manage the actual “tab” for the application as a ZmAppButton. For example, you can obtain a handle to the tab “button” through the app chooser and set, among other things, the text label & the tool tip.

var controller = appCtxt.getAppController();
var appChooser = controller.getAppChooser();

// change the tab label and tool tip
var appButton = appChooser.getButton(this._tabAppName);
appButton.setText("NEW TAB LABEL");
appButton.setToolTipContent("NEW TAB TOOL TIP");

The Content Areas

You can set the various content areas of the tab to suit your Zimlet needs. The Toolbar area is the area directly under the row of tab applications. This is typically the place where you put toolbar buttons for application control. The Overview area is located on the left-side of the page. This area typically houses a navigation tree but you can set any content you see fit. The Main area is the primary content location for the tab and can be set with whatever application content as needed.

The Toolbar Area can be obtained from the ZmZimletApp and is represented as a ZmToolBar object:

var app = appCtxt.getApp(this._tabAppName);
var toolbar = app.getToolbar();
toolbar.setContent("<b>TAB APPLICATION - TOOLBAR AREA</b>");

The Main Area can be accessed directly from the ZmZimletApp:

var app = appCtxt.getApp(this._tabAppName);
app.setContent("<b>TAB APPLICATION - MAIN AREA</b>");

The Overview Area can be obtained from the ZmZimletApp and is represented as a ZmOverview object:

var app = appCtxt.getApp(this._tabAppName);
var overview = app.getOverview();
overview.setContent("<b>TAB APPLICATION - OVERVIEW AREA</b>");

So that’s the basics of tab applications and Zimlets. As you can see, by leveraging this new Zimlet Tab feature, you will be able to create new & powerful integrations with Zimbra Collaboration Suite.

More information on implementing your own Zimlet tab application can be found in the Zimlet Developer’s Guide at:

http://wiki.zimbra.com/index.php?title=ZCS_6.0:Zimlet_Developers_Guide:Introduction

http://wiki.zimbra.com/index.php?title=ZCS_6.0:Zimlet_Developers_Guide:Zimlet_Tab

Zimlet Tab Examples are available at:

http://wiki.zimbra.com/index.php?title=ZCS_6.0:Zimlet_Developers_Guide:Example_Zimlets#Tab_Zimlets

And checkout the Zimlet JavaScript API Reference for information on the ZmZimletBase class and tab application methods such as createApp(), appAction() and appLaunch():

http://files.zimbra.com/docs/zimlet/zcs/6.0/jsdocs/index.html

When developing a Zimlet, you are constantly making code changes and then packaging and deploying the Zimlet to be able to test those changes. This is the Zimlet development process and is done over & over again until your Zimlet is “ready” for production. An iterative development process like this that involves packaging and deploying with each code change can be quite time consuming and really impact your developer productivity.

That’s where the Zimlet Development Directory comes in.

By using the Zimlet Development Directory, you can develop your Zimlets without having to package and deploy the Zimlet with each code change. You can make your code changes directly in the Zimlet files and just refresh your browser to see the changes take affect. This will greatly reduce your development time and overall, make it much easier to build Zimlets.

To use the Zimlet Development Directory, create a _dev folder in the {zcs-install-dir}/zimlets-deployed directory. In the _dev folder, create your Zimlet folder and file structure that you can modify on the fly. It’s just that easy.

For example, say you want to create a Zimlet named “com_zimbra_myzimlet”:

1. Create the development directory:
   {zcs-install-dir}/zimlets-deployed/_dev
2. Create the Zimlet folder:
   {zcs-install-dir}/zimlets-deployed/_dev/com_zimbra_myzimlet
3. Now put your Zimlet Definition File (com_zimbra_myzimlet.xml) and whatever other resources your Zimlet needs in that directory (like JavaScript files, JSP files, Properties files, etc).
4. Make code changes to the Zimlet files as necessary and voila, just refresh your browser to see the changes take affect.

There are some limitations, however. If using Internationalization resource properties, you will need to load the Zimbra Web Client in Development Mode (i.e. with “?dev=1″ on the URL). Also, the “allowed domains” setting in the Zimlet Configuration File (config_template.xml) for the Proxy Servlet is not recognized. There is a workaround for this situation described in the Proxy Servlet Setup section of the Zimlet Developer’s Guide.

We still recommend that you package and deploy your Zimlet when you plan to go into production. But as you can see, the Zimlet Development Directory cuts-out the deploy & package development steps and is a convenient way to do iterative Zimlet development.

More information on the Zimlet Development Directory can be found in the Zimlet Developer’s Guide at:

http://wiki.zimbra.com/index.php?title=ZCS_6.0:Zimlet_Developers_Guide:Dev_Environment_Setup#Zimlet_Development_Directory

This is one people have asked about a lot. Starting with Zimbra Collaboration Suite 6.0, we will be providing a formal Zimlet Developer’s Guide and API Reference. The goal of this documentation is to make it easier for partners and customers to build Zimlets and to integrate with the Zimbra platform. As we’ve built this documentation, here are some of our guiding principles:

• Easy to find. Make the documentation online and “wiki-based” for easy access.
• Reduce “wondering” between versions. Maintain documentation with each ZCS release so when new major versions of ZCS are delivered (and changes are made to the APIs), people on older ZCS releases can still access their “version specific” documentation.
• Lower overhead to get started. Make developing Zimlets possible without having to download the entire product source. Of course, product source will still be available for those who want it but we want to make even advanced Zimlet tasks (for example, compiling templates) possible without needed the entire source tree.

Here are links to the new developer documentation:

Zimlet Developer’s Guide for ZCS 6.0
http://wiki.zimbra.com/index.php?title=ZCS_6.0:Zimlet_Developers_Guide:Introduction

Zimlet Definition File Reference for ZCS 6.0
http://wiki.zimbra.com/index.php?title=ZCS_6.0:Zimlet_Developers_Guide:Zimlet_Definition_File_Reference

Zimlet JavaScript API Reference for ZCS 6.0
http://files.zimbra.com/docs/zimlet/zcs/6.0/jsdocs/index.html

These are living documents and we will be adding content & more information over the coming weeks. With this first-launch, we are looking for your thoughts on the best ways you enjoy learning and making use of the new material, as well as ideas and suggestions about Zimlet topics that you think we should cover. Please provide feedback and comments in the forums at:

http://www.zimbra.com/forums/zimlets/35951-new-zimlet-developer-documentation-zcs-6-0-available.html

Pay attention to the extra bar at the top to navigate around the wiki pages:

Whether you just want dozens of examples, a list of all the elements in the Zimlet Definition File…or want to dive into advanced topics like Templates and Portals, we plan to leave no stone unturned.

Happy coding!

Many of our partners, customers, administrators and end users have seen the Microsoft announcement regarding a roadmap to document the Outlook Personal Storage Table (.pst) file format, and have expressed their curiosity about it’s impact on Zimbra products. While it is still unknown if documentation will provide enough insight on how to really unlock the Outlook PST, we see it as the first step in providing new functionality in future versions of Zimbra Collaboration Suite and Zimbra Desktop that access the terabytes of data in PSTs.

For more than a decade, many attempts have been made to understand the Outlook file format, and products have struggled to provide PST support on platforms other than Windows. All efforts have come up short for one reason or another. As Paul Lorimer mentions in his blog post: MAPI and OOM libraries have been available to access PST content, but those libraries are available only to Microsoft programs where Outlook is installed. This dependency forces customers contemplating an OS or platform switch to include email data portability as factor in their decision.

Customers believe this is not a long-term acceptable scenario.  As a result, the software industry is in the midst of a gradual transition, moving from proprietary API and data models to open source and standards based options to prevent data lock-in and to encourage data sharing across applications.  But why haven’t companies spent more time or moved more quickly to open-up their platforms and data given the market’s trend line?

Companies have externally argued that the standards are not complete, or are in conflict with competing standards or they have just not seen the customer demand.  Internally they traditionally weigh existing revenue and investment in developing their proprietary APIs against creating & implementing open formats with greater potential reach and less well understood revenue impact. What has resulted is a string of complicated interoperability and conversion tools, with limited features and ambiguous product life cycles.

There is a lot of discussion out there about the meaning of openness, as noted in the recent Google blog, which has certainly garnered it’s share of comments (see John Grubber’s response or Matt Asay’s response). Regardless of the larger ongoing debate, historically, Microsoft has used data formats, like PST, to create application lock-in and as a wedge to drive commercial business. This only works for so long. Customer benefit has little to do with the underlying data store and more about user features.

Zimbra was built on the belief that a winning recipe is balancing an open system and support for standards with the commercial aspects of the business. Zimbra has always provided access to our core application source code and has been a huge proponent of open formats, throwing strong support behind standards like CalDAV. This platform and technology openness, as Matt Asay points out, allows vendors to focus on solving customer problems, not on the nuances and licensing (i.e. control) of underlying data.

We applaud the effort by Microsoft to help free their user’s data and feel this announcement is another piece of evidence that the need for “openness” has surpassed critical mass. We eagerly await release of the final PST documentation.

Zimbra’s massive user base means our new product releases reach farther than ever before. How far? Consider our 50 million paid mailbox count. With that comes the responsibility to make our solutions exactly what people need when it comes to shaping the future of communication.

So what are some of the top requested features included in the first release of Zimbra Collaboration Suite 6.0?

Sync your phone like never before.

We’ve added user trigger-able device wipe, server policies, and tasks to the existing MobileSync support for email, contacts, and appointments.

Arrange and personalize the interface.

Read and compose multiple messages in tabs without the need for pop-out windows using the advanced AJAX client. Widescreen? Move the reading pane to the side.

Presentation Framework.

Create new presentations (as well as documents and spreadsheets) from the briefcase – no need for external software to run them.

 

 

Calendar views. Direct CalDav connections. Streamlined contacts.

Our feature rich UI has new layouts including fisyeye and a sortable list view. Access an external ICS/CalDAV url – with adjustable automatic update polling frequencies. For the address book: Rather than pages of blanks to fill out, add only the contact fields you want.

Lite-client overhauls galore.

The standard HTML client now includes all our primary apps, plus the ability to drag items like it’s AJAX cousin. Using a web-browser on your mobile device? There’s multiple variants based on device type and connection speed. We’ve added appointment management functionality to the portable web-client, a simplified login page, as well as file access.

Role based administration.

Delegate. Empower distribution list managers without worrying about them accidentially changing major server settings. Even let someone add or remove members, but not create or delete existing lists – the views and ACL rights are that customizable. Hosting providers can now give one account permission to manage multiple domains or adjust class-of-service features.

 

 

Connect with your social world.

Zimlets now have the ability to define application or preferences tabs. So use the new Social Zimlet to manage Twitter, Facebook, or just browse Digg. Try the Discover Zimlet to visit all that Del.icio.us has to offer.

Share Management.

Join a new group? Get up to speed fast – receive and an instant email about all the available shares. Didn’t accept that invite long ago but turns out you need something? Rather than digging it up, just use the new share tool to see what you have permissions on; or have given to others.

Server Architecture Improvements.

A few of the powerful under-the-hood changes include a new OpenLDAP engine with the ability to make on the fly config tweaks, SQLite & RRD for logger, customizable hierarchical storage queries. Plus we’ve exposed a UI for the stats service – giving you quick insight on just about everything you can think of.