Zimbra Server
Zimbra Server
Zimbra Server
Zimbra Server
Incoming Mail Routing
The Zimbra server is a dedicated server that manages all of the mailbox contents, including
messages, contacts, calendar, Documents notebooks, and attachments. Messages are
received from the Zimbra MTA server and then passed through any filters that have been
created. Messages are then indexed and deposited into the correct mailbox.
Each Zimbra mailbox server in the system can see only its own storage volumes. Zimbra
mailbox servers cannot see, read, or write to another Zimbra server.
In a Zimbra single server environment, all services are on one server, and during installation
the computer is configured to partition the disk to accommodate each of the services.
In a Zimbra multi-server environment, the Zimbra LDAP and Zimbra MTA services can be
installed on separate servers. See the Multi-Server Installation Guide.
Disk Layout
The mailbox server includes the following volumes:
• Message Store. Mail message files are in opt/zimbra/store
• Data Store. The MySQL database files are in opt/zimbra/db
• Index Store. Index files are in opt/zimbra/index
• Log files. Each component in the Zimbra Collaboration Suite has log files. Local logs are
in /opt/zimbra/log
Message Store
The Zimbra Message Store is where all email messages reside, including the message
body and any file attachments. Messages are stored in MIME format.
The Message Store is located on each Zimbra server under
/opt/zimbra/store. Each mailbox has a dedicated directory named after its internal Zimbra
mailbox ID.
Single copy storage allows messages with multiple recipients to be stored only once in the
file system. On UNIX systems, the mailbox directory for each user contains a hard link to the
actual file.
Data Store
The Zimbra Data Store is a MySQL database that contains all the metadata regarding the
messages including tags, conversations, and pointers to where the messages are stored in
the file system.
Each account (mailbox) resides only on one server. Each Zimbra server has its own stand
alone data store containing data for the mailboxes on that server.
The Data Store contains:
• Mailbox-account mapping. The primary identifier within the Zimbra database is the
mailbox ID, rather than a user name or account name. The mailbox ID is only unique
within a single mailbox server. The Data Store maps the Zimbra mailbox IDs to the users’
OpenLDAP accounts.
• Each user’s set of tag definitions, folders, and contacts, calendar appointments, filter
rules.
• Information about each mail message, including whether it is read or unread, and which
tags are associated.
Index Store
The index and search technology is provided through Apache Lucene. Each message is
automatically indexed as it enters the system. Each mailbox has an index file associated
with it.
The tokenizing and indexing process is not configurable by administrators or users.
The process is as follows:
1. The Zimbra MTA routes the incoming email to the Zimbra mailbox server that contains the
account’s mailbox.
2. The mailbox server parses the message, including the header, the body, and all readable
file attachments such as PDF files or Microsoft Word documents, in order to tokenize the
words.
3. The mailbox server passes the tokenized information to Lucene to create the index files.
Note: Tokenization is the method for indexing is by each word. Certain common patterns,
such as phone numbers, email addresses, and domain names are tokenized as shown in
Figure 3.
Figure 3: Message tokenization
Redo Log
Each Zimbra server generates redo logs that contain every transaction processed by that
server. If an unexpected shutdown occurs to the server, the redo logs are used for the
following:
• To ensure that no uncommitted transactions remain, the server rereads the redo logs
upon startup.
• During restore, to recover data written since the last full backup in the event of a server
failure.
When the current redo log file size reaches 100MB, the current redo log rolls over to an
archive directory. At that point, the server starts a new redo log. All uncommitted
transactions from the previous redo log are preserved. In the case of a crash, when the
server restarts, the current redo log and the archived logs are read to re-apply any
uncommitted transactions.
Log
A Zimbra deployment consists of various third-party components with one or more Zimbra
mailbox servers. Each of the components may generate its own logging output.
Selected Zimbra log messages generate SNMP traps, which you can capture using any
SNMP monitoring software. See Monitoring Zimbra Servers.
Zimbra Server