Zimbra Collaboration Administrator Guide

Key functions built into the system for user identity management are summarized in the following table:

Functions built into the system to secure data are summarized in the following table:

The Zimbra Collaboration system logs — generated by SNMP triggers — can be used to record data such as user and administrator activity, login failures, slow queries, mailbox activity, mobile synchronization activity, and data based errors. Events, alerts and traps can be forwarded to log management and event correlation system to create centralized polices and notifications based on your security and compliance requirements.

Licenses are automatically activated if the Zimbra Collaboration server has a connection to the Internet and can communicate with the Zimbra License server. If you are unable to activate your license this way, see the next section on Manual License Activation.

For systems that do not have external access to the Zimbra License server, you can use the Zimbra Support Portal to activate your license manually.

Go to the Zimbra website at https://www.zimbra.com and click on Support to display the Zimbra Technical Support page. Click on the Support Portal Login button to display the Zimbra Support Portal page. Enter your email and password to log in.

If you have problems accessing the Support Portal, contact Zimbra Sales at sales@zimbra.com or by calling 1-972-407-0688.688.

If you fail to install or activate your Zimbra Collaboration server license, the following scenarios describe the impact on your Zimbra Collaboration server.

You must have a Zimbra Collaboration license to create accounts. When you purchase, renew, or change the Zimbra license, you must update the Zimbra server with the new license information. The Update License Wizard from the Administration Console’s Global Settings is used to upload and install a new license. The Activate License link on the toolbar activates the license.

View current license information, including the number of purchased accounts, the number of accounts used, and the expiration date, in the Admin Console.

When your Zimbra Collaboration Network Edition License expires, a license expiration warning appears in the administrative console and web interface for all users. From the date of the license expiration, there is a 30-day grace period during which the administrator sees the warning message, but no features are disabled.

Upon expiration of the grace period, the server reverts to the feature set of the Open Source Edition. The following is a list of some of the major functions that are no longer available upon license expiration:

If you exhaust your licensed user limit, you are no longer able to create accounts. You can buy additional user licenses, or you can delete existing accounts. Contact Zimbra sales to purchase additional licenses.

You must renew your license within 30 days of the expiration date. Starting 30 days before the license expires, when you log on to the Administration Console, a reminder notice is displayed.

All email messages are stored in MIME format in the Message Store, including the message body and file attachments.

By default, the message store is located on each mailbox server under /opt/zimbra/store. Each mailbox has its own directory named after its internal mailbox ID. Mailbox IDs are unique per server, not system-wide.

Messages with multiple recipients are stored as a single -copy on the message store. On UNIX systems, the mailbox directory for each user contains a hard link to the actual file.

When Zimbra Collaboration is installed, one index volume and one message volume are configured on each mailbox server. Each mailbox is assigned to a permanent directory on the current index volume. When a new message is delivered or created, the message is saved in the current message volume.

To manage your email storage resources, you can configure storage volumes for older messages by implementing a Hierarchical Storage Management (HSM) policy. See Managing Configuration.

The Data Store is a SQL database where internal mailbox IDs are linked with user accounts. All the message metadata including tags, conversations, and pointers indicate where the messages are stored in the file system. The SQL database files are located in /opt/zimbra/db.

Each account (mailbox) resides only on one server. Each server has its own standalone data store containing data for the mailboxes on that server.

The index and search technology is provided through Apache Lucene. Each email message and attachment is automatically indexed when the message arrives. An index file is associated with each account. Index files are located in /opt/zimbra/index.

The tokenizing and indexing process is not configurable by administrators or users.

The process is as follows:

Mailstore services provides the back-end access to mailbox/account data. Webapps for the mailstore include:

User Interface services provide front-end user interface access to the mailbox account data and Administration Console, including:

For installation and configuration of the Web Application Server Split, see the Zimbra Collaboration Multi-Server Installation Guide.

The internal authentication method uses the Zimbra schema running on the OpenLDAP directory server. For accounts stored in the OpenLDAP server, the userPassword attribute stores a salted-SHA512 (SSHA512) digest of the user’s password. The user’s provided password is computed into the SSHA digest and then compared to the stored value.

External LDAP and external Active Directory authentication can be used if the email environment uses another LDAP server or Microsoft Active Directory for authentication and Zimbra LDAP for all other Zimbra Collaboration related transactions. This requires that users exist in both OpenLDAP and in the external LDAP server.

The external authentication methods attempt to bind to the specified LDAP server using the supplied user name and password. If this bind succeeds, the connection is closed and the password is considered valid.

The zimbraAuthLdapURL and zimbraAuthLdapBindDn attributes are required for external authentication.

You can implement a custom authentication to integrate external authentication to your proprietary identity database. When an authentication request comes in, Zimbra checks the designated auth mechanism for the domain. If the auth mechanism is set to custom authentication, Zimbra invokes the registered custom auth handler to authenticate the user.

To set up custom authentication, prepare the domain for the custom auth and register the custom authentication handler.

Kerberos5 Authentication Mechanism authenticates users against an external Kerberos server.

To specify Kerberos5 for an individual account set the account’s zimbraForeignPrincipal as kerberos5:{kerberos5-principal}. For example: kerberos5:user1@MYREALM.COM.

The Attributes Mapped to Zimbra Collaboration Contact table maps generic GAL search attributes to their Zimbra Collaboration contact fields.

LDAP attributes are mapped to GAL entry fields. For example, the LDAP attribute displayName and cn can be mapped to GAL entry field fullName. The mapping is configured in the zimbraGalLdapAttrMap attribute.

GAL is configured on a per-domain basis. To configure the attributes, you can run the GAL Configuration Wizard from the Administration Console.

Additions, changes and deletions to the GAL attributes are made through the Zimbra Administration Console or from the zmprov commands.

Users can modify attributes for their account in the directory. When users change their options from the Zimbra Web Client, they also modify the attributes when they change their preferences.

When you add or change theme (skin) property files and locale resource files for ZCS on a server, you must flush the cache to make the new content available.

When you modify the account, COS, groups, domain, and server attributes, the change is effective immediately on the server to which the modification is done. On the other servers, the LDAP entries are automatically updated after a period of time if the attributes are cached.

The default ZCS setting to update the server is 15 minutes. The caching period is configured on local config key.

If you do not specify a name or ID along with the type, all entries in cache for that type are flushed and the cache is reloaded.

When you modify global config attributes, the changes are effective immediately on the server to which the modification is done. On other mailbox servers, you must flush the cache to make the changes available or restart the server. LDAP entries for global config attributes do not expire.

Some global config attributes are computed into internal representations only once per server restart. For efficiency reasons, changes to those attributes are not effective until after a server restart, even after the cache is flushed. Also, some global configuration settings and server settings that are inherited from global config are only read once at server startup, for example port or number of processing threads. Modifying these types of attributes requires a server restart.

To flush the cache for global config changes on all servers:

Zimbra modified Postfix files — main.cf and master.cf — specifically to work with ZCS:

You can enable restrictions so that messages are not accepted by Postfix when non-standard or other disapproved behavior is exhibited by an incoming SMTP client. These restrictions provide some protection against spam senders. By default, clients that do not greet with a fully qualified domain name are restricted. DNS based restrictions are also available.

You can configure Postfix to send nonlocal mail to a different SMTP server, commonly referred to as a relay or smart host.

A common use case for a relay host is when an ISP requires that all your email be relayed through a designated host, or if you have filtering SMTP proxy servers.

The relay host setting must not be confused with Web mail MTA setting. Relay host is the MTA to which Postfix relays non-local email. Webmail MTA is used by the Zimbra server for composed messages and must be the location of the Postfix server in the Zimbra MTA package.

To use the Administration Console to configure Relay MTA for external delivery:

ClamAV software is the virus protection engine enabled for each ZCS server.

The anti-virus software is configured to put messages that have been identified as having a virus to the virus quarantine mailbox. By default, the Zimbra MTA checks every two hours for any new anti-virus updates from ClamAV.

You can change anti-virus settings at the Administration Console.

Zimbra uses SpamAssassin to identify unsolicited commercial email (spam) with learned data stored in either the Berkeley DB database or a MariaDB database. You can also use the Postscreen function to provide additional protection against mail server overload. Both strategies are described in the following topics:

When the Zimbra MTA receives mail, it routes the mail through a series of queues to manage delivery; incoming, active, deferred, hold, and corrupt.

The incoming message queue holds the new mail that has been received. Each message is identified with a unique file name. Messages are moved to the active queue when there is room. If there are no problems, message move through this queue very quickly.

The active message queue holds messages that are ready to be sent. The MTA sets a limit to the number of messages that can be in the active queue at any one time. From here, messages are moved to and from the anti-virus and anti-spam filters before being delivered to another queue.

Messages that cannot be delivered are placed in the deferred queue. The reasons for the delivery failures are documented in a file in the deferred queue. This queue is scanned frequently to resend the message. If the message cannot be sent after the set number of delivery attempts, the message fails and is bounced back to the original sender. You can choose to send a notification to the sender that the message has been deferred.

The hold message queue keeps mail that could not be processed. Messages stay in this queue until the administrator moves them. No periodic delivery attempts are made for messages in the hold queue.

The corrupt queue stores damaged unreadable messages.

You can monitor the mail queues for delivery problems from the Administration Console. See Monitoring ZCS Servers.

The message for external domains can also be modified.

Following are the instructions:

When a user receives mail from an external domain, the edited message banner will get displayed at the top of the message body.

The following ports are used either by Zimbra Proxy or by Zimbra Mailbox (if Proxy is not configured). If you have any other services running on these ports, turn them off.

End clients connect directly to Zimbra Proxy, using the Zimbra Proxy Ports. Zimbra Proxy connects to the Route Lookup Handler or Zimbra Mailbox using the Zimbra Mailbox Ports.

Zimbra Proxy has the ability to strictly enforce which values are allowed in the Host header passed in by the client.

This is enabled by default on new installations but left disabled for upgrades from previous versions unless toggled during the installation.

The functionality may be altered by setting the zimbraReverseProxyStrictServerNameEnabled boolean configuration option followed by restarting the proxy server.

When the strict server name functionality is enabled, additional valid server names may be specified using the zimbraVirtualHostName and zimbraVirtualIPAddress configuration items at the domain level.

IMAP proxy is installed with Zimbra Collaboration and set up during installation from the configuration menus. To set up the HTTP proxy, the proxy must be installed on the identified proxy nodes in order to set up HTTP proxy. No other configuration is usually required.

If you need to, set up IMAP/POP proxy after you have already installed HTTP proxy, and set up the mailbox server and the proxy node.

To set up HTTP proxy, Zimbra Proxy must be installed on the identified nodes.

When a proxy is configured with ZCS, each proxy server’s IP address must be configured in LDAP attribute zimbraMailTrustedIP to identify the proxy addresses as trusted when users log in through the proxy. The proxy IP address is added to the X-Forwarded-For header information. The X-Forwarded-For header is automatically added to the localconfig zimbra_http_originating_ip header attribute. When a user logs in, this IP address and the user’s address are verified in the Zimbra mailbox log.

Set each proxy IP address in the attribute. For example, if you have two proxy servers:

You can change the password - from either the Administration Console or the CLI - at any time.

From the Administration Console, use the Change Password screen to set the new password string, and to define the policy for user password modifications.

Double click select user account or from the Gear icon, select Change Password from the popup menu.

A different login and logout page can be configured either as a global setting or as a domain setting.

To specify a URL to redirect administrators to if their login fails authentication, or if their authentication has expired:

Global:

Domain:

To specify a URL to redirect administrators to, for logging out:

Global:

Domain:

The options provided in the Home navigation pane get categorized under the Home directory. Some of the options lead to configuration pages; others lead to pages containing reports, as associated with your selections.

The illustration at right is an expanded view of the options currently supported in the Navigation Pane.

The upper bar of the in-view page always displays your current position in the hierarchy, and you can use multiple options for dismissing the current view:

The Navigation pane options are described in the following topics:

The Home screen is the default, login view, which provides the Home navigation pane and the Home page. This page provides a snapshot view of system status and a series of quick-access links for essential tasks.

The Monitor screen provides the Monitor navigation pane and the Monitor pages, which display various itemizations about servers monitored by the Collaborator.

The Manage screen provides the Manage navigation pane, and the Manage pages, which display the tables categorically provided as Accounts, Aliases, Distribution Lists, and Resources that are currently managed by Collaborator.

The Configure screen provides the Configure navigation pane, and the Configure pages, which enable configurations for individual or global components.

Global Settings define the default global values for servers, accounts, COS, and domains. These default values and parameters apply when no specific values and parameters for particular items are in their settings.

You configure the defaults for Global Settings during installation. You can change the settings at any time from Global Settings at the Administration Console.

The Tools and Migration screen provides the Tools and Migration navigation pane, for access to system software management and system backup/restore. Administrators can access and download specific wizards and tools from this page.

The Search screen displays the Search results from queries made in the Search field in the Administration Console header.

The Help Center is a reference of resources available from the online help and documentation, which you can access with the links provided in the Help Center screen. Use this page, also, to access community forums and to view expert responses to the top migration questions.

The selection of a category from the Navigation pane typically results in a tabular display of all managed objects for the selected category. All tables display labeled columns in which to view information such as email addresses, display names, status, last logins, and descriptions (if configured).

Each row in a table enables actions you can perform if you require additional information or access to the configuration for the selected table entry.

To remove a message from view, click Close located alongside the message content.

Use the zimbraAdminConsoleLoginMessage attribute, with guidelines in this section, to create a single message of the day, or to create multiple messages to be displayed.

Creating a global message or domain-specific message.

Creating a multiple-message display:

Use the zimbraAdminConsoleLoginMessage attribute, with guidelines in this section, to delete a single message of the day, or to delete multiple messages.

Removing a specific message:

Removing all messages:

The following illustration provides a high-level view of the Administration Console UI.

You can select options to perform on a selected entity from the navigation pane from the Gear icon or a topical popup menu.

The Administration Console logically groups a wide range of Configuration options into containers. Applicable configuration options inside these containers are listed in the High-level View of Administration Console UI

By default, all containers on a page are opened (expanded). You can opt to close (collapse) containers - which can free up additional space in a page view - by clicking on collapse/expand located at the upper-left edge of the container.

An administrator creates the account for you on the Zimbra Collaboration Server and gives you the migration tool application and the following information which you need to migrate your PST files.

In the Results dialog, view the migration status of the PST file, including progress, errors, and warnings.

To view the results log, double click your account. A new tab opens and displays the account log information.

Once the command runs successfully, the console displays the status of the migration.

Global email attachment settings allow you to specify global rules for handling attachments to an email message. You can also set rules by COS and for individual accounts. When attachment settings are configured in Global Settings, the global rule takes precedence over COS and Account settings.

See Blocking Email Attachments by File type for information about this section of the screen.

You can also reject messages with certain types of files attached. You select which file types are unauthorized from the Common extensions list. You can also add other extension types to the list. Messages with those type of files attached are rejected. By default the recipient and the sender are notified that the message was blocked.

If you do not want to send a notification to the recipient when messages are blocked, you can disable this option.

Use the IMAP and POP pages to enable global access.

IMAP and POP3 polling intervals can be set from the Administration Console COS Advanced page.
Default = No polling interval.

With POP3, users can retrieve their mail stored on the Zimbra server and download new mail to their computer. The user’s POP configuration in their Preference → Mail page determines how their messages are downloaded and saved.

Use the New Domain Wizard to set options described in this section.

The Global Address List (GAL) is your company-wide listing of users that is available to all users of the email system. GAL is a commonly used feature in mail systems that enables users to look up another user’s information by first or last name, without having to know the complete email address.

GAL is configured on a per-domain basis. The GAL mode setting for each domain determines where the GAL lookup is performed.

Use the GAL Mode Settings tool with your domain configuration to define the Global Address List.

A GAL sync account is created for the domain when an internal or external GAL is created, and if you have more than one mailbox server, you can create a GAL sync account for each mailbox server in the domain. Using the GAL sync account gives users faster access to auto complete names from the GAL.

When a GAL sync account is created on a server, GAL requests are directed to the server’s GAL sync account instead of the domain’s GAL sync account. The GalSyncResponse includes a token which encodes the GAL sync account ID and current change number. The client stores this and then uses it in the next GalSyncRequest. Users perform GAL sync with the GAL sync account they initially sync with. If a GALsync account is not available for some reason, the traditional LDAP-based search is run.

When you configure the GAL sync account, you define the GAL datasource and the contact data is synced from the datasource to the GAL sync accounts' address books. If the mode Both is selected, an address book is created in the account for each LDAP data source.

The GAL polling interval for the GAL sync determines how often the GALsync account syncs with the LDAP server. The sync intervals can be in x days, hours, minutes, or seconds. The polling interval is set for each data source.

When the GAL sync account syncs to the LDAP directory, all GAL contacts from the LDAP are added to the address book for that GAL. During the sync, the address book is updated with new contact, modified contact and deleted contact information. You should not modify the address book directly. When the LDAP syncs the GAL to the address book, changes you made directly to the address book are deleted.

You create GALsync accounts from the Administration Console. The CLI associated with this feature is zmgsautil.

Authentication is the process of identifying a user or a server to the directory server and granting access to legitimate users based on user name and password information provided when users log in.

Set the authentication method on a per-domain basis.

Virtual hosting allows you to host more than one domain name on a server. The general domain configuration does not change.

When you create a virtual host, this becomes the default domain for user login; users can log in without having to specify the domain name as part of their user name.

To open the Zimbra Web Client log in page, users enter the virtual host name as the URL address. For example, https://mail.company.com.

When the Zimbra login screen displays, users enter only their user name and password. The authentication request searches for a domain with that virtual host name. When the virtual host is found, the authentication is completed against that domain.

You can limit the number of accounts that can be provisioned on a domain. The maximum number of accounts that can be provisioned for the domain can be set when the domain is created. You can also edit the domain configuration to add or change the number.

In the Administration Console this is set for a domain in the Account Limits page. If this page is not configured, no limits on the domain are set.

Resources, spam, and ham accounts are not counted against this limit.

When multiple Classes of Service (COS) are available, you can select which classes of service can be configured and how many accounts on the domain can be assigned to the COS. This is configured in the domain’s Account Limits page. The number of COS account types used is tracked. The limits for all COSs cannot exceed the number set for the maximum accounts for the domain.

The number of COS assigned to accounts is tracked. You can see the number assigned/number remaining from any account’s General Information page.

When you rename a domain you are actually creating a new domain, moving all accounts to the new domain and deleting the old domain. All account, alias, distribution list, and resource addresses are changed to the new domain name. The LDAP is updated to reflect the changes.

Before you rename a domain

After the domain has been renamed

A domain alias allows different domain names to direct to a single domain address. For example, your domain is domain.com, but you want users to have an address of example.com, you can create example.com as the alias for the domain.com address. Sending mail to user@example.com is the same as sending mail to user@domain.com.

Disclaimers are set per-domain. When upgrading, an existing global disclaimer is converted to domain specific disclaimers on every domain to preserve behavior with previous releases.

Per domain disclaimer support can be enabled using the following steps:

You can enable the option for emails between individuals in the same domain to not have a disclaimer attached.

Set the attribute attachedzimbraAmavisOutboundDisclaimersOnly to TRUE.

To preserve backward-compatibility, this attribute defaults to FALSE.

It is possible to completely remove support for disclaimers by setting the related attribute to FALSE.

All Zimlets that are deployed are displayed in the domain’s Zimlets page. If you do not want all the deployed Zimlets made available for users on the domain, select from the list the Zimlets that are available for the domain. This overrides the Zimlet settings in the COS or for an account.

The General Information page includes the following configuration information:

When installing a reverse proxy the communication between the proxy server and the backend mailbox server must be in plain text. Checking This server is a reverse proxy lookup target automatically sets the following parameters:

The Notes text box can be used to record details you want to save.

The MTA page show the following settings:

If the server has multiple IP addresses, you can use IP address binding to specify which specific IP addresses you want a particular server to bind to.

A certificate is the digital identity used for secure communication between different hosts or clients and servers. Certificates are used to certify that a site is owned by you.

Two types of certificates can be used - self-signed and commercial certificates.

When Zimbra Collaboration is installed, the self-signed certificate is automatically installed and can be used for testing Zimbra Collaboration. You should install the commercial certificate when Zimbra Collaboration is used in your production environment.

To generate the Certificate Signing Request (CSR) you complete a form with details about the domain, company, and country, and then generate a CSR with the RSA private key. You save this file to your computer and submit it to your commercial certificate authorizer.

To obtain a commercially signed certificate, use the Zimbra Certificates Wizard in the Administration Console to generate the RSA Private Key and CSR.

Use guidelines from the Install Certificates table to set parameters for your certificates.

Download the CSR from the Zimbra server and submit it to a Certificate Authority, such as VeriSign or GoDaddy. They issue a digitally signed certificate.

When you receive the certificate, use the Certificates Wizard a second time to install the certificate on Zimbra Collaboration. When the certificate is installed, you must restart the server to apply the certificate.

You can view the details of certificates currently deployed. Details include the certificate subject, issuer, validation days and subject alternative name.

Certificates display for different Zimbra services such as LDAP, mailboxd, MTA and proxy.

It is important to keep your SSL certificates valid to ensure clients and environments work properly, as the ZCS system can become non-functional if certificates are allowed to expire. You can view deployed SSL certificates from the ZCS administrator console, including their validation days. It is suggested that certificates are checked periodically, so you know when they expire and to maintain their validity.

You can install an SSL certificate for each domain on a Zimbra Collaboration server. Zimbra Proxy must be installed on Zimbra Collaboration and correctly configured to support multiple domains. For each domain, a virtual host name and Virtual IP address are configured with the virtual domain name and IP address.

Each domain must be issued a signed commercial certificate that attests that the public key contained in the certificate belongs to that domain.

Configure the Zimbra Proxy Virtual Host Name and IP Address.

Edit the certificate for the domain:

Copy the domain’s issued signed commercial certificates and private key files to the Domain Certificate section for the selected domain.

DKIM signing to outgoing mail is done at the domain level.

To set up DKIM you must run the CLI zmdkimkeyutil to generate the DKIM keys and selector. You then update the DNS server with the selector which is the public key.

When the DKIM keys are updated, the DNS server must be reloaded with the new TXT record.

Good practice is to leave the previous TXT record in DNS for a period of time so that email messages that were signed with the previous key can still be verified.

Log in to the ZCS server and as zimbra:

Optional. To specify the number of bits for the new key, include -b in the command line, -b <####>. If you do not add the -b, the default setting is 2048 bits.

Removing DKIM signing deletes the DKIM data from LDAP, and new email messages are no longer signed for the domain. When you remove DKIM from the domain, it is a good practice to leave the previous TXT record in DNS for some time so that email messages that were signed with the previous key can still be verified.

Use the following command syntax to remove the file:

Use the following command syntax to view the stored DKIM information for the domain, selector, private key, public signature and identity:

The automated spam training filter is enabled by default and two feedback system mailboxes are created to receive mail notification.

The mailbox quota and attachment indexing is disabled for these training accounts. Disabling quotas prevents bouncing messages when the mailbox is full.

How well the anti-spam filter works depends on recognizing what is considered spam. The SpamAssassin filter learns from messages that users specifically mark as spam by sending them to their junk folder or not spam by removing them from their junk folder. A copy of these marked messages is sent to the appropriate spam training mailbox.

When ZCS is installed, the spam/ham cleanup filter is configured on only the first MTA. The ZCS spam training tool, zmtrainsa, is configured to automatically retrieve these messages and train the spam filter. The zmtrainsa script is enabled through a crontab job to feed mail to the SpamAssassin application, allowing SpamAssassin to 'learn' what signs are likely to mean spam or ham. The zmtrainsa script empties these mailboxes each day.

The ZCS default is that all users can give feedback when they add or remove items from their junk folder.

If you do not want users to train the spam filter you can disable this function.

When these attributes are modified, messages marked as spam or not spam are not copied to the spam training mailboxes.

Initially, you might want to train the spam filter manually to quickly build a database of spam and non-spam tokens, words, or short character sequences that are commonly found in spam or ham. To do this, you can manually forward messages as message/rfc822 attachments to the spam and non-spam mailboxes.

When zmtrainsa runs, these messages are used to teach the spam filter. Make sure you add a large enough sampling of messages to get accurate scores. To determine whether to mark messages as spam at least 200 known spams and 200 known hams must be identified.

To reduce the risk of backscatter spam, you can run a service that runs a Zimbra Access Policy Daemon that validates RCPT To: content specifically for alias domains.

The postfix_policy_time_limit key is set because by default the Postfix spawn(8) daemon kills its child process after 1000 seconds. This is too short for a policy daemon that might run as long as an SMTP client is connected to an SMTP process.

Disable the SMTPD policy.

Define the policy restriction.Setting Email Recipient RestrictionsRealtimeBlackhole Lists and Realtime Right-Hand Side Blocking/Black Lists can be turned on or off in the MTA.