The Zimbra Collaboration Suite is designed to provide an end-to-end mail solution that is scalable and highly reliable. The messaging architecture is built with well-known open-system technology and standards and is composed of a mail server application and a client interface.
Administrators can easily manage domains, servers, and accounts from the browser based administration console and can manage backup, bulk provision accounts, and perform cross-mailbox searches from the Command Line Utility.
Zimbra architecture includes open-source integrations using industry standard protocols. The third-party software listed below is bundled with Zimbra software and installed as part of the installation process. These components have been tested and configured to work with the software.
Figure 1 shows the Zimbra Collaboration Suite architectural design, including the open-source software bundled with the Suite and other recommended third-party applications.
The Zimbra Collaboration Suite uses the OpenLDAP software, an open source LDAP directory server. User authentication is provided through OpenLDAP. Each account on the Zimbra server has an unique mailbox ID that is the primary point of reference to identify the account.
Postfix is the open source mail transfer agent (MTA) that receives email via SMTP and routes each message to the appropriate Zimbra mailbox server using Local Mail Transfer Protocol (LMTP). The Zimbra MTA also includes the anti-virus and anti-spam components.
The Zimbra store package installs the components for the mailbox server, including Apache Tomcat, which is the servlet container the Zimbra software runs within. Each account is configured on one mailbox server, and this account is associated with a mailbox that contains all the mail messages and file attachments for that mail account.
As each mail arrives, the Zimbra server schedules a thread to have the message indexed (index store). Any attachments to the mail message are scheduled to be converted to HTML, and then the HTML version is scheduled to be indexed.
The data store is a MySQL database where internal mailbox IDs are linked with user accounts. The data store maps the mailbox IDs to users’ OpenLDAP accounts. This database contains each user’s set of tag definitions, folders, calendar schedules, and contacts, as well as the status of each mail message - read, unread, tags associated to message, and folder the message resides in.
The message store is where all email messages and file attachments reside. Messages are stored in MIME format. A message that is sent to multiple recipients who have accounts on one mailbox server are stored only once in the file system.
As each email message arrives, the Zimbra server schedules a thread to have the message indexed. Any attachments to the mail message are scheduled to be converted to HTML, and then the HTML version is scheduled to be indexed.
Installing the Zimbra-SNMP package is optional. If you choose to install Zimbra-SNMP for monitoring, the package should be run on every server (Zimbra server, Zimbra LDAP, Zimbra MTA) that is part of the Zimbra configuration. Zimbra uses swatch to watch the syslog output to generate SNMP traps.
Installing the Zimbra Logger package is optional and is installed on one mailbox server. The Zimbra logger installs tools for syslog aggregation, reporting, and message tracing. If you do not install Logger, you cannot use the message trace feature. In addition, the server statistics are not captured, and the server statistics section of the administration console will not display.
Installing the Zimbra Spell package is optional. Aspell is the open source spell checker used on the Zimbra Web Client. When Zimbra-spell is installed, the Zimbra-apache package is also installed.
Zimbra includes a configurable backup manager that resides on every Network Edition Zimbra server and performs both backup and restore functions. You do not have to stop the server in order to run the backup process. You can use the backup manager to restore a single user in the event that one user’s mailbox becomes corrupted. See
Backup and Restore.
Table 1 lists the main directories created by the Zimbra installation packages.
The exact configuration for each deployment is highly dependent on variables including the number of mailboxes, mailbox quotas, performance requirements, existing network infrastructure, IT policies, security methodologies, spam filtering requirements, and so forth.
Figure 2 shows a typical configuration with incoming traffic and user connection. Alternate ways of configuring at many points within the network are possible.