Zimbra Collaboration Suite Administrator s Guide. Release 6.0

(1)

Zimbra

™

Collaboration Suite

Administrator’s Guide

Release 6.0

Network Edition

(2)

No part of this document may be reproduced, in whole or in part, without the express written permission of Zimbra.

Trademark and Licensing

MySQL is a registered trademark of MySQL AB in the United States, the European Union and other countries.

OpenLDAP is a registered trademark of the OpenLDAP Foundation.

SpamAssassin is a trademark of Deersoft, Inc.

This product includes software developed by the Apache Software Foundation (http://www.apache.org/). All other marks are the property of their respective owners.

Building Better Products within the Open Source Community

Zimbra Collaboration Suite leverages many great technologies from the open source community: MySQL, OpenLDAP, Postfix, SpamAssassin, and Apache. Zimbra believes that great products come from contributing to and leveraging open source technologies. We are thankful for the great contributions that led to the creation of MySQL, OpenLDAP, Postfix, SpamAssassin, and Apache software.

Zimbra, a division of VMware, Inc. 3401 Hillview Avenue

Palo Alto , California 94304 USA www.Zimbra.com

September 2009 - ZCS 6.0 Revised for 6.0.8

(3)

zmcertmgr . . . 262 zmgsautil . . . 263 zmldappasswd . . . 264 zmlocalconfig . . . 265 zmmailbox . . . 266 zmtlsctl . . . 268 zmhsm . . . 269 zmlicense . . . 270 zmmetadump . . . 271 zmmypasswd . . . 271 zmplayredo . . . 271 zmproxyconfgen . . . 272 zmproxypurge . . . 273 zmredodump . . . 274 zmskindeploy . . . 275 zmsoap . . . 275 zmstat-chart . . . 276 zmstat-chart-config . . . 277 zmstatctl . . . 277 zmthrdump . . . 278 zmtrainsa . . . 278 zmtzupdate . . . 279 zmvolume . . . 279 zmzimletctl . . . 280 zmproxyconfig . . . 281

Appendix B ZCS Crontab Jobs . . . 285

How to read the crontab . . . 285

ZCS Cron Jobs . . . 286

Jobs for crontab.store . . . 286

Jobs for crontab.logger . . . 287

Jobs for crontab.mta . . . 287

Single Server Crontab -l Example . . . 288

Appendix C The zmlocalconfig Settings . . . 291

Appendix D Glossary . . . 295

(10)

(11)

Chapter 1 Introduction

Zimbra™ Collaboration Suite is a full-featured messaging and collaboration solution that includes email, address book, calendaring, tasks, and Web document authoring.

Intended Audience

This guide is intended for system administrators responsible for installing, maintaining, and supporting the server deployment of Zimbra.

Readers of this guide should possess the following recommended knowledge and skill sets:

• Familiarity with the associated technologies and standards, including Red Hat® Enterprise Linux® operating system, SUSE operating systems, and open source concepts

• Industry practices for mail system management

Zimbra Collaboration Suite License

A Zimbra license is required in order to create accounts on the Network Edition Zimbra Collaboration Suite servers. You can install ZCS without a license but only one account, the administrator account, can be created. A trial and a regular license are available:

• Trial. You can obtain the trial license from the Zimbra license portal for free. The trial license allows you to create up to 50 users. It expires in 60 days. • Regular. You must purchase the Zimbra regular license. This license is

valid for a specific Zimbra Collaboration Suite system and is encrypted with the number of Zimbra accounts (seats) you have purchased, the effective date and expiration date of the regular license.

Also see the Zimbra Mailbox Server chapter, Zimbra Mailbox Server.

Go to Zimbra’s Website to obtain a trial license from the Network Downloads link. Contact Zimbra Sales to purchase a regular license by emailing

(12)

Available Documentation

The following ZCS documentation is available:

• Installation Guides. Installation guides for single server and multi-server installation, include system requirements and server configuration

instructions.

• Administrator Guide. This guide provides a comprehensive product overview, including architecture, server functionality, administration tasks, configuration options, and monitoring tools.

• ZCS Migration Wizard Guides. The guides provides instructions for running the Migration Wizard to migrate accounts from either Microsoft Exchange servers or Lotus Domino servers.

• Zimbra administration console Help. The Help topics describes how to perform tasks required to centrally manage ZCS servers and mailbox accounts from the administration console.

• Zimbra Web Client Help. The Help topics describes how to use the features of the ZCS Web Client.

• Release Notes. Late-breaking news for product releases and upgrade instructions are contained in the release notes. The latest notes can be found on the Zimbra Website, www.zimbra.com.

Support for Recommended Third-Party Components

Where possible, Zimbra adheres to existing industry standards and open source implementations for backup management, user authentications, operating platform, and database management. However, Zimbra only supports the specific implementations described in the Zimbra Collaboration Suite architecture overview in the Product Overview chapter as officially tested and certified for the Zimbra Collaboration Suite. This document may

occasionally note when other tools are available in the marketplace, but such mention does not constitute an endorsement or certification.

Support and Contact Information

Visit www.Zimbra.com to join the community and to be a part of building the best open source messaging solution. We appreciate your feedback and suggestions.

• Contact sales@Zimbra.com to purchase Zimbra Collaboration Suite • Network Edition customers can contact support at support@zimbra.com • Explore the Zimbra Forums for answers to installation or configurations

problems

(13)

Introduction

Let us know what you like about the product and what you would like to see in the product. Post your ideas to the Zimbra Forum.

(14)

(15)

Chapter 2 Product Overview

This chapter describes the Zimbra application architecture, integration points, and information flow.

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.

The architecture includes the following core advantages:

• Open source integrations. Linux®, Jetty, Postfix, MySQL®, OpenLDAP®. • Uses industry standard open protocols. SMTP, LMTP, SOAP, XML,

IMAP, POP.

• Modern technology design. Java, JavaScript thin client, DHTML.

• Horizontal scalability. Because each mailbox server includes its own data store, message store, and set mailbox accounts, you don’t change

anything on existing servers in order to scale the system. To scale for additional mail accounts, add more servers.

• High availability support. For cluster integration to provide high availability, ZCS can integrate with either Red Hat® Enterprise Linux® Cluster Suite version 4, Update 5 or later or with Veritas™ Cluster Server by Symantec (VCS) version 5.0 with maintenance pack 1 or later.

• Browser based client interface. Zimbra Web Client gives users easy access to all the ZCS features.

• Administration console to manage accounts and servers.

Core Functionality

The Zimbra Collaboration Suite is an innovative messaging and collaboration application that offers the following state-of-the-art messaging and

collaboration solutions: • Email

(16)

• Task Management

• Web document management and authoring. The core functionality within ZCS is as follows: • Mail delivery and storage

• Indexing of mail messages upon delivery • Backup services

• Mailbox server logging • IMAP and POP support • Directory services • Anti-spam protection • Anti-virus protection

Administrators can easily manage domains, servers, and accounts from the browser based administration console.

• Manage classes of service • Add accounts and domains

• Set account restrictions either for an individual account or by COS • Delegate users as domain administrators

• Move mailboxes from one server to another • Create and edit distribution lists

• Import Microsoft Exchange user accounts • Set up virtual hosts on a domain

• Manage servers

• View and manage system status

• Define policies for moving older messages to secondary storage • Backup and restore accounts

• Monitor usage

Zimbra offers two browser based web clients, Advanced Zimbra Web Client that offers a state-of-the-art Ajax web client; and Standard Zimbra Web Client as an HTML client. Some of the features that can be found in the web client include:

• Compose, read, reply, forward, and use other standard mail features • View mail by conversation threads

• Tag mail to easily group messages for quick reference • Perform advanced searches

(17)

Product Overview

• Use Calendar to schedule appointments

• Share calendar, email folders, address book lists with others • Create address books and share with others

• Set mailbox usage preferences, including defining mail filtering options • Use ZCS Documents to create, organize and share web documents • Use the Tasks feature to create to-do lists and manage tasks through to

completion.

Zimbra Components

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.

• Jetty, the web application server that Zimbra software runs in.

• Postfix, an open source message transfer agent (MTA) that routes mail messages to the appropriate Zimbra server

• OpenLDAP software, an open source implementation of the Lightweight Directory Access Protocol (LDAP) that provides user authentication • MySQL database software

• Lucene, an open-source full featured text and search engine

• Verity®, a third-party source that converts certain attachment file types to HTML

• Anti-virus and anti-spam open source components including:

• ClamAV, an anti-virus scanner that protects against malicious files • SpamAssassin mail filter that attempt to identify spam

• Amavisd-new, which interfaces between the MTA and one or more content checkers

• James/Sieve filtering, used to create filters for email

System Architecture

(18)

Figure 1: Zimbra Collaboration Suite System Architecture

Zimbra Packages

The Zimbra Collaboration Suite includes the following application packages.

Zimbra application runs inside of mailboxd mailboxd Backups To disk Meta-Data Store MySQL File system Message store Lucene store OpenLDAP User account data

Option for Microsoft Active Directory Server (AD) for auth and GAL

End user interface JavaScript browser application Administrator console JavaScript browser application Postfix Mail routing Microsoft Edge MTA SOAP/HTTP(S) SOAP/HTTP(S) SMTP LMTP Exchange

Option to import users from pre-existing Exchange server

Logging

3p Third-party (proprietary) 3p Third-party (open source)

3p

* Your choice of technologies * 3p 3p 3p 3p 3p 3p Monitoring Tools such as swatch * Load balancing

Inbound spam filtering

Anti-virus & Anti-spam plug-ins ClamAV anti-virus (outbound)

(19)

Zimbra Core

The Zimbra Core package includes the libraries, utilities, monitoring tools, and basic configuration files.

Zimbra Convertd

Zimbra-convertd package is installed on the zimbra-store server. Only one zimbra-convertd package needs to be present in the ZCS environment. Zimbra LDAP

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.

The OpenLDAP schema has been customized for the Zimbra Collaboration Suite.

Zimbra MTA (mail routing server)

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.

Zimbra Store (Zimbra server)

The Zimbra store package installs the components for the mailbox server, including Jetty, which is the servlet container the Zimbra software runs within. Within ZCS, this servlet container is called mailboxd.

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.

The mailbox server includes the following components: • Data store

• Message store • Index store

• HTML attachment conversion utility

Each Zimbra server has its own standalone data store, message store and store for the mailboxes on that server.

As each email arrives, the Zimbra server (convertd) extracts the text from the attachments to be indexed along with the mail body.

Attachments are converted to HTML when users click on the view as HTML

(20)

Data store. 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.

Message store. 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.

Index store. Index and search technology is provided through Lucene. Index files are maintained for each mailbox.

Zimbra-SNMP

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.

Zimbra Logger

Installing the Zimbra Logger package is optional and is installed on one mailbox server. The Zimbra logger installs tools for syslog aggregation, reporting. If you do not install Logger, the server statistics section of the administration console will not display.

Zimbra Spell

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 Proxy

Installing the Zimbra Proxy is optional. Use of an IMAP/POP proxy server allows mail retrieval for a domain to be split across multiple Zimbra servers on a per user basis.

Note: The Zimbra Proxy package can be installed with the Zimbra LDAP, the

Zimbra MTA, the Zimbra Mailbox server, or on its own server.

Zimbra Memcached

(21)

Zimbra Archiving

The Zimbra Archiving and Discovery feature is an optional feature for Zimbra Network Edition. Archiving and Discovery offers the ability to store and search all messages that were delivered to or sent by Zimbra. This package includes the cross mailbox search function which can be used for both live and archive mailbox searches. Note: Using Archiving and Discovery can trigger additional mailbox license usage. To find out more about Zimbra Archiving and

Discovery, contact Zimbra sales.

Backup Process Overview

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 Chapter 16, Backup and Restore.

Zimbra System Directory Tree

Table 1 lists the main directories created by the Zimbra installation packages. The directories not listed in this table are libraries used for building the core Zimbra software

Note: The directory organization is the same for any server in the Zimbra

Collaboration Suite, installing under /opt/Zimbra.

Table 1 Directory Structure for Zimbra Components

Parent Directory Description

/opt/

Zimbra/ Created by all Zimbra installation packages

backup/ Backup target contains full and incremental backup data

bin/ Zimbra application files, including the utilities described in Appendix A, Command -Line Utilities

clamav Clam AV application files for virus and spam controls

conf/ Configuration information

contrib Third party scripts for conveyance

convertd Convert service

(22)

data/ldap/

hdb OpenLdap data directory

db/ Data Store

doc/ SOAP txt files

dspam DSPAM antivirus

httpd Spell server

/ Store

java/ Contains Java application files

jetty/ mailboxd application server instance. In this directory, the webapps/Zimbra/skins directory includes the Zimbra UI theme files.

lib/ Libraries

libexec/ Internally used executables

log/ Local logs for Zimbra server application

logger/ RRD and SQLite data files for logger services

mysql/ MySQL database files

openldap/ OpenLDAP server installation, pre-configured to work with Zimbra

postfix/ Postfix server installation, pre-configured to work with Zimbra

redolog/ Contains current transaction logs for the Zimbra server

sleepycat/ Berkeley DB

snmp/ SNMP monitoring files

ssl/ Certificates

store/ Message store

wiki Contains the Zimbra Documents global template file

(23)

Example of a Typical Multi-Server Configuration

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.

zimbramon/ Contains the control scripts and Perl modules

zimlets Contains Zimlet zip files that are installed with Zimbra

zimlets-extra

Contains Zimlet zip files that can be installed

zimlets-network

Contains Zimlet zip files for features that are installed with the network edition.

(24)

Figure 2: Typical Configuration with Incoming Traffic and User Connections

Explanation of Figure 2 follows:

Zimbra LDAP Mounted Backup disk Zimbra LDAP Zimbra Server Edge MTA spam filtering Edge MTA Load balancer firewalls external end user Internet mail Load balancer Zimbra MTA Zimbra MTA internal end users & administrator users

Zimbra Server

Internet mail (inbound) External user connection Internal user connection Replication (optional) Backup

LDAP directory traffic

master replica

virus and spam

1 2 3 4 5 6 7 8 filtering

1 Inbound Internet mail goes through a firewall and load balancing to the edge MTA for spam filtering.

2 The filtered mail then goes through a second load balancer. 3 An external user connecting to the messaging server also goes

through a firewall to the second load balancer.

(25)

5 The designated Zimbra MTA server looks up the addressee’s directory information from the Zimbra LDAP replica server.

6 After obtaining the user’s information from the Zimbra LDAP server, the MTA server sends the mail to the appropriate Zimbra server. 7 Internal end-user connections are made directly to any Zimbra

server which then obtains the user’s directory information from Zimbra LDAP and redirects the user as needed.

(26)

(27)

Chapter 3 Zimbra Mailbox Server

The Zimbra mailbox 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.

In addition to content management, the Zimbra mailbox server has dedicated volumes for backup and log files.

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 ZCS 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 ZCS multi-server environment, the LDAP and MTA services can be installed on separate servers. See the Multi-Server Installation Guide.

Zimbra Licenses

A Zimbra license is required in order to create accounts. See “Zimbra

(28)

Incoming Mail Routing

The MTA server receives mail via SMTP and routes each mail message to the appropriate Zimbra mailbox server using LMTP. As each mail message arrives, the Zimbra server schedules a thread to have Lucene index it.

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

• Backup Area. Full and incremental backups are in opt/zimbra/backup

• Log files. Each component in the Zimbra Collaboration Suite has log files. Local logs are in /opt/zimbra/log

Note: The system logs, the redo logs, and the backup disk should be on

separate disks to minimize the possibility of unrecoverable data loss in the event that one of those disks fails.

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.

Note: Mailbox IDs are unique per server, not system-wide. Single-Copy Message Storage

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.

Hierarchical Storage Management

(29)

Zimbra Mailbox Server

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, tasks notebooks, and 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.

Figure 3: Message tokenization

stanford.edu stanford.edu stanford edu Word List documents words containing word word 1 2 3 4 Lucene “Jo Brown” <jb@ZCS.com>

(30)

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 by each word. Certain

common patterns, such as phone numbers, email addresses, and domain names are tokenized as shown in Figure 3.

Backup

Zimbra includes a configurable backup manager that resides on every Zimbra server and performs both backup and restore functions. You do not have to stop the Zimbra server in order to run the backup process. The backup manager can be used to restore a single user, rather than having to restore the entire system in the event that one user’s mailbox becomes corrupted. See Chapter 16, Backup and Restore.

Redo Log

Each Zimbra mailbox server generates redo logs that contain current and archived transactions processed by the message store server since the last incremental backup.

When the server is restored, after the backed up files are fully restored, any redo logs in the archive and the current redo log in use are replayed to bring the system to the point before the 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 are read to re-apply any uncommitted transactions.

When an incremental backup is run, the redo logs are moved from the archive to the backup directory.

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.

(31)

Chapter 4 Zimbra Directory Service

The Zimbra LDAP service is a directory service running a version of the OpenLDAP software that has the Zimbra schema already installed. This chapter describes how the directory service is used for user authentication and account configuration and management.

Note: Zimbra also supports integration with Microsoft’s Active Directory

Server. Contact Zimbra support for more detailed information on specific directory implementation scenarios.

The LDAP server is identified when ZCS is installed. Each server has its own LDAP entry that includes attributes specifying operating parameters. In addition, there is a global configuration object that sets defaults for any server whose entry does not specify every attribute.

A selected subset of these attributes can be modified through the Zimbra administration console; others can be changed through the CLI utility.

Directory Services Overview

LDAP directory services provide a centralized repository for information about users and devices that are authorized to use your network. The central repository used for Zimbra’s LDAP data is the OpenLDAP directory server. Figure 4 shows traffic between the Zimbra-LDAP directory server and the other servers in the Zimbra system. The Zimbra MTA and the Zimbra mailbox server read from, or write to, the LDAP database on the directory server. The edge MTA does not connect to the LDAP database; instead, it uses the DNS server’s MX entry to determine where to direct mail.

(32)

Figure 4: LDAP Directory Traffic

At the core of every LDAP implementation is a database organized using a schema. The schema specifies the types of objects that are stored in the database, and what types of attributes they have.

An LDAP directory entry consists of a collection of attributes and has a globally unique distinguished name (DN). The attributes allowed for an entry are determined by the object classes associated with that entry. The values of the object class attributes determine the schema rules the entry must follow. The object classes determine what type of object the entry refers to and what type of data can be stored for that entry. An entry’s object class that

determines what kind of entry it is, is called a structural object class and cannot be changed. Other object classes are called auxiliary and may be added to or deleted from the entry.

Use of auxiliary object classes in LDAP allows for an object class to be combined with an existing object class. For example, an entry with structural object class inetOrgPerson, and auxiliary object class zimbraAccount, would

be an account, either administrator or end-user. An entry with the object class

zimbraServer would be a server in the Zimbra system that has one or more Zimbra packages installed.

LDAP Hierarchy

LDAP directories are arranged in an hierarchal tree-like structure. In the Zimbra system, the structure is arranged based on Internet domain names. LDAP entries typically include items such as user accounts, organizations, or servers.

Figure 5 shows the Zimbra LDAP hierarchy. Each type of entry (object) has certain associated object classes.

directory server Zimbra mailbox

(33)

Zimbra Directory Service

Figure 5: Zimbra LDAP Hierarchy

For a complete listing of the Zimbra auxiliary object classes, see the Zimbra LDAP Schema.

Zimbra Schema

Every LDAP implementation has a schema that defines its domain structure, account attributes, and other data structures in use by the organization. Zimbra includes a custom LDAP schema that extends the generic schema included with OpenLDAP software and is designed to potentially coexist with existing directory installations. The Zimbra server, the administration console, the command-line account provisioning, and the management utilities require the Zimbra schema.

All attributes and object classes specifically created for Zimbra are prefaced by “zimbra,” as in zimbraMailRecipient object class or the

zimbraAttachmentsBlocked attribute.

The Zimbra schema assumes a baseline schema. In the OpenLDAP installer package included with Zimbra, the following schema files are included in the OpenLDAP implementation:

• core.schema • cosine.schema

• inetorgperson.schema • zimbra.schema

Note: You cannot modify the Zimbra schema.

Account Authentication

This section describes the account authentication mechanisms and formatting directives supported:

cn=zimbra

cn=admins cn=confg cn=cos cn=servers

dc=com

dc=zimbra

ou=people

(34)

• Internal

• External LDAP

• External Active Directory

The Internal authentication method assumes the Zimbra schema running on the OpenLDAP directory server.

The External LDAP and External Active Directory authentication methods

attempt to bind to the specified LDAP server, using the supplied user name and password. These methods can be used if the email environment uses Microsoft Active Directory directory services for authentication and the

Zimbra-LDAP directory services for all other Zimbra-related transactions. This requires that users exist in both OpenLDAP and in the Active Directory servers.

The authentication method type is set on a per-domain basis, using the

zimbraAuthMech attribute, with other information also coming from the domain. If this attribute is not set, the default is to use the internal method as the authentication.

Internal Authentication Mechanism

For accounts stored in the OpenLDAP server, the userPassword attribute stores a salted-SHA1 (SSHA) digest of the user’s password. This information is not used to connect to the directory server; it is only used to compare with the information on the OpenLDAP server, using a pool of re-usable

administrator LDAP connections.

External LDAP and External Active Directory Authentication

Mechanism

Unlike the internal authentication mechanism, the external authentication mechanism attempts to bind to the directory server using the supplied user name and password. If this bind succeeds, the connection is closed and the password is considered valid.

Two additional domain attributes are required for the external mechanism:

zimbraAuthLdapURL and zimbraAuthLdapBindDn. zimbraAuthLdapURL Attribute and SSL

The zimbraAuthLdapURL attribute contains the URL of the Active Directory server to bind to. This should be in the form:

ldap://ldapserver:port/

(35)

Examples include:

ldap://server1:389 ldap://exch1.acme.com

For SSL connection, use ldaps: instead of ldap:. If the SSL version is used, the SSL certificate used by the server must be configured as a trusted certificate. zimbraAuthLdapBindDn Attribute

The zimbraAuthLdapBindDn attribute is a format string used to determine which user name to use when binding to the Active Directory server. During the authentication process, the user name starts out in the format:

user@domain.com

The user name may need to be transformed into a valid LDAP bind dn (distinguished name). In the case of Active Directory, that bind dn might be in a different domain.

Custom Authentication - zimbraCustomAuth

You can implement a custom authentication on your domain. Custom authentication allows external authentication to your proprietary identity database. When an AuthRequest comes in, Zimbra checks the designated auth mechanism for the domain. If the auth mechanism is set to custom auth, 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.

Preparing a domain for custom auth

To enable a domain for custom auth, set the domain attribute, zimbraAuthMet to custom:{registered-custom-auth-handler-name}.

For example:

zmprov modifydomain {domain|id} zimbraAuthMech custom:sample.

In the above example, “sample” is the name under which a custom auth mechanism is registered.

Registering a custom authentication handler To register a custom authentication handler, invoke

ZimbraCustomAuth.register [handlerName, handler] in the init method of the extension.

• Class: com.zimbra.cs.account.ldap.zimbraCustomAuth

(36)

Note: Definitions

• handlername is the name under which this custom auth handler is

registered to Zimbra’s authentication infrastructure. This is the name that is set in the domain’s zimbraAuthMech attribute. For example, if the registered name is “sample”, than zimbraAuthMech must be set to custom:sample.

• handler is the object on which the authenticate method is invoked

for this custom auth handler. The object has to be an instance of zimbraCustomAuth (or subclasses of it).

Example

How Custom Authentication Works

When an AuthRequest comes in, if the domain is specified to use custom auth, the authenticating framework invokes the authenticate method on the

ZimbraCustomAuth instance passed as the handler parameter to

ZimbraCustomAuth.register ().

The account object for the principal to be authenticated and the clear-text password entered by the user are passed to the ZimbraCustomAuth

.authenticate () method. All attributes of the account can be retrieved from the account object.

Kerberos5 Authentication Mechanism

Kerberos5 Authentication Mechanism authenticates users against an external Kerberos server. To set up Kerberos5 auth set the domain attribute

zimbraAuthMech to kerberos5. Then set the domain attribute

zimbraAuthKerberos5Realm to the Kerberos5 realm in which users in this domain are created in the Kerberos database.

When users log in with an email password and the domain, zimbraAuthMech is set to kerberos5, the server constructs the Kerberos5 principal by

{localpart-of-public class SampleExtensionCustomAuth implements ZimbraExtension { public void init() throws ServiceException {

/*

* Register to Zimbra's authentication infrastructure *

* custom:sample should be set for domain attribute zimbraAuthMech */

ZimbraCustomAuth.register("sample", new SampleCustomAuth()); }

(37)

the-email}@{value-of-zimbraAuthKerberos5Realm} and uses that to authenticate to the kerberos5 server.

Kerberos5 can be supported for individual accounts. This is done by setting the account’s zimbraForeignPrincipal as kerberos5. Set the account's

zimbraForeignPrincipal as kerberos5:{kerberos5-principal}. For example: kerberos5:user1@MYREALM.COM. If zimbraForeignPrincipal starts with

“kerberos5:”, the server uses {kerberos5-principal} as the Kerberos5 principal instead of the algorithm of grabbing the realm from the

zimbraAuthKerberos5Realm as mentioned in the previous paragraph.

Zimbra Objects

Zimbra uses auxiliary object classes to add Zimbra-specific attributes to existing objects such as an account. The LDAP objects used in Zimbra include the following:

• Accounts

• Class of Service (COS) • Domains • Distribution Lists • Recipients • Servers • Global Configurations • Aliases • Zimlet • CalendarResource • Identity • Data Source • Signature Accounts Object

An account object represents an account on the Zimbra mailbox server that can be logged into. Account entrees are either administrators or user accounts that can be logged into. The object class name is zimbraAccount. This object class extends the zimbraMailRecipient object class.

The object class zimbraMailRecipient is a directory entry that represents an entity that can receives mail. This is a visible external mail address that is expanded through aliases or forwarding into one or more internal/external addresses.

All accounts have the following properties:

(38)

• A unique ID that never changes and is never reused

• A set of attributes, some of which are user-modifiable (preferences) and others that are only configurable by the system administrator

All user accounts are associated with a domain, so a domain must be created before creating any accounts.

For more about account provisioning, see the Chapter 11, Managing User Accounts.

Class of Service (COS) Object

Class of Service is a Zimbra-specific object that defines the default attributes an email account has and what features are added or denied. The COS controls features, default preference settings, mailbox quotas, message lifetime, password restrictions, attachment blocking and server pools for creation of new accounts. The object class name is zimbraCOS.

Domains Object

A Domains object represents an email domain such as example.com or

example.org. A domain must exist before email addressed to users in that

domain can be delivered. The object class name is zimbraDomain. Distribution ListsObject

Distribution lists, also known as mailing lists, are used to send mail to all members of a list by sending a single email to the list address. The object class name is zimbraDistributionList.

RecipientObject

Recipient object represents an entity that can receive mail. An external email address exists, and the recipient can be expanded through aliases or

forwarding into one or more internal/external addresses. The object class name is zimbraMailRecipient. This object class name is only used in conjunction with zimbraAccount and zimbraDistributionlist classes. ServersObject

The servers object represents a particular server in the Zimbra system that has one or more of the Zimbra software packages installed. During the installation, the software is automatically registered on the OpenLDAP server. The object class name is zimbraServer. Attributes describe server

(39)

Global ConfigurationObject

The Global Configuration object specifies default values for the following objects: server, account, COS, and domain. If the attributes are not set for other objects, the values are inherited from the global settings. The object class name is zimbraGlobalConfig.

Global configuration values are required and are set during installation as part of the Zimbra core package. These become the default values for the system. AliasObject

Alias object is a placeholders in the directory to reserve a name. The object class name is zimbraAlias. The attribute points to another entry.

Zimlet Object

Zimlet Object defines Zimlets that are installed and configured in Zimbra. The object class name is zimbraZimletEntry. See the Working with Zimlets chapter for more information about Zimlets.

CalendarResource Object

CalendarResource object defines a calendar resource such as conference rooms or equipment that can be selected for a meeting. The object class name is zimbraCalendarResource.

Identity Object

Identity object represents a persona of a user. A persona contains the user’s identity such as display name and a link to the signature entry used for outgoing emails. A user can create multiple personas. Identity entries are created under the user’s LDAP entry in the DIT. The object class name is

zimbraIdentity. Data Source Object

Data source object represents an external mail source of a user. The two types of data source are POP3 and IMAP. A data source contains the POP3/ IMAP server name, port, and password for the user’s external email account. The data source also contains persona information, including the display name and a link to the signature entry for outgoing email messages sent on behalf of the external account. Data Source entries are created under the user’s ldap entry in the DIT. The object class name is zimbraDataSource. Signature Object

(40)

Company Directory/GAL

A company directory is a company-wide listing of users, usually within the organization itself, that is available to all users of the email system.

Sometimes called “white pages” or global address list (GAL), Zimbra uses the company directory to look up user addresses from within the company.

For each domain used in Zimbra, you can choose from the following GAL search options:

• Use an external LDAP server for the GAL • Use the Zimbra implementation in OpenLDAP

• Include both external LDAP server and OpenLDAP in GAL searches GAL Searches in Zimbra Client

The Zimbra client can search the GAL. The GAL search returns a list of directory entries that match the user’s search.

When the user supplies a name to search for, that name is turned into an LDAP search filter similar to the following example:

The string “%s” is replaced with the name the user is searching for. GAL Attributes in Zimbra

Two possible sources for GAL information are the Zimbra server and the Active Directory server. The relevant LDAP/Active Directory fields are referenced in the Zimbra schema under the same names as listed in the Active Directory schema.

Table 1 maps generic GAL search attributes to their Zimbra contact fields. (|(cn = %s*)(sn=%s*)(gn=%s*)(mail=%s*))

(zimbraMailDeliveryAddress = %s*) (zimbraMailAlias=%s*)

(zimbraMailAddress = %s*)

Table 1 Attributes Mapped to Zimbra contact Standard LDAP Attribute Zimbra Contact Field

co workCountry

company Company

givenName/gn firstName

sn lastName

(41)

Zimbra GAL Search Parameters

Like authentication, GAL is configured on a per-domain basis. From the administration console, you can run the GAL Configuration Wizard to configure the domain’s attributes.

Modifying Attributes

The OpenLDAP directory should not be modified directly. Any additions, changes and deletions are made through the Zimbra administration console or from the CLI utility for provisioning, zmprov.

Users modify attributes for their entry (accounts) in the OpenLDAP directory when they change their options from the Zimbra Web Client.

Administrators can also modify LDAP attributes using the command-line tools described in “Appendix A Command-Line Utilities” on page 227.

Important: Do not use any LDAP browsers to change the Zimbra LDAP

content.

Flushing LDAP Cache

The Zimbra LDAP server caches the following types of entries • Themes (skins) • Locales • Account • COS • Domains initials initials l workCity

street, streetaddress workStreet

postalCode workPostalCode

telephoneNumber workPhone

st workState

title jobTitle

mail email

objectClass Not currently mapped

(42)

• Global configuration • Server

• Zimlet configuration

Themes and Locales

When you add or change skin (themes) properties files and local resource files for ZCS on a server, you flush the cache to reload the new content. Until you do this, the new skins and locales are not available in the COS or Account. • To flush skins, type zmprov flushCache skin

• To flush locales, type: zmprov flushCache locale

Note: Flushing the skin/locale cache only makes the server aware of the

resource changes. It does not automatically modify any COS or account’s LDAP zimbraAvailableSkin and zimbraAvailableLocal settings. The LDAP attributes must be modified separately either from the administration console or with the zmprov ma command.

Accounts, COS, Domains, and Servers

When you modify Account, COS, 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. Use zmprov flushCache to make the changes available immediately on a server.

Note: The default ZCS setting for updating the server is 15 minutes. • To flush accounts, COS, domain, and server caches, type zmprov

flushCache [account|cos|domain|server] [name|id]

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.

Note: Some server attributes are not effective until after a server restart,

even after the cache is flushed. For example, settings like bind port or number of processing threads.

Global Configuration

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.

Note: Some global config attributes are computed into internal

(43)

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 make a global config change effective on all servers do the following: 1. Modify the setting using zmprov mcf. For example, type zmprov mcf

zimbraImapClearTextLoginEnabled.

Note: The change is only effective on the server

zimbra_zmprov_default_soap_server, port zimbra_admin-service_port.

2. Flush the global config cache on all other servers, zmprov flushCache must be issued on all servers, one at a time. For example:

(44)

(45)

Chapter 5 Zimbra MTA

The Zimbra MTA (Mail Transfer Agent) receives mail via SMTP and routes each message, using Local Mail Transfer Protocol (LMTP), to the appropriate Zimbra mailbox server.

The Zimbra MTA server includes the following programs:

• Postfix MTA, for mail routing, mail relay, and attachment blocking

• Clam AntiVirus, an antivirus engine used for scanning email messages and attachments in email messages for viruses

• SpamAssassin, a mail filter that attempts to identify unsolicited commercial email (spam), using a variety of mechanisms

• Amavisd-New, a Postfix content filter used as an interface between Postfix and ClamAV / SpamAssassin

In the Zimbra Collaboration Suite configuration, mail transfer and delivery are distinct functions. Postfix primarily acts as a Mail Transfer Agent (MTA) and the Zimbra mail server acts as a Mail Delivery Agent (MDA).

MTA configuration is stored in LDAP and a configuration script automatically polls the LDAP directory every two minutes for modifications, and updates the Postfix configuration files with the changes.

Zimbra MTA Deployment

The Zimbra Collaboration Suite includes a precompiled version of Postfix. This version does not have any changes to the source code, but it does include configuration file modifications, additional scripts, and tools.

Postfix performs the Zimbra mail transfer and relay. It receives inbound messages via SMTP, and hands off the mail messages to the Zimbra server via LMTP, as shown in Figure 6. The Zimbra MTA can also perform anti-virus and anti-spam filtering.

(46)

Figure 6: Postfix in a Zimbra Environment

*

Edge MTA The term edge MTA is a generic term referring to any sort of edge security solution for mail. You may already deploy such solutions for functions such as filtering. The edge MTA is optional. Some filtering may be duplicated between an edge MTA and the Zimbra MTA.

Postfix Configuration Files

Zimbra modified the following Postfix files specifically to work with the Zimbra Collaboration Suite:

• main.cf Modified to include the LDAP tables. The configuration script in the Zimbra MTA pulls data from the Zimbra LDAP and modifies the Postfix configuration files.

• master.cf Modified to use Amavisd-New.

Important: Do not modify the Postfix configuration files directly! Some of the

Postfix files are rewritten when changes are made in the administration console. Any changes you make will be overwritten.

MTA Functionality

Zimbra MTA Postfix functionality includes: • SMTP authentication

• Attachment blocking • Relay host configuration • Postfix-LDAP integration

Zimbra MTA

Zimbra mail server SMTP

LMTP

Storage format

Edge MTA* Spam and Virus filtering _{Message blocking (some types)}

Mail routing Mail relay

Alias/list expansion

Directory services

Alias/list information Routing to Zimbra hosts

Virus and Spam filtering (Postfix)

(47)

Zimbra MTA

• Integration with Amavisd-New, ClamAV, and Spam Assassin

SMTP Authentication

SMTP authentication allows authorized mail clients from external networks to relay messages through the Zimbra MTA. The user ID and password is sent to the MTA when the SMTP client sends mail so the MTA can verify if the user is allowed to relay mail.

Note: User authentication is provided through the Zimbra LDAP directory

server, or if implemented, through the Microsoft Active Directory Sever.

SMTP Restrictions

In the administration console, 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 ill-behaved spam senders. By default, SMTP protocol violators (that is, clients that do not greet with a fully qualified domain name) are restricted. DNS based restrictions are also available.

Important: Understand the implications of these restrictions before you

implement them. You may want to receive mail from people outside of your mail system, but those mail systems may be poorly implemented. You may have to compromise on these checks to accommodate them.

Relay Host Settings

Postfix can be configured to send all non-local mail to a different SMTP server. Such a destination SMTP server is commonly referred to as a relay or smart host. You can set this relay host from the administration console.

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

In the administration console, 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. Important: Use caution when setting the relay host to prevent mail loops.

MTA-LDAP Integration

The Zimbra LDAP directory service is used to look up email delivery

(48)

Account Quota and the MTA

Account quota is the storage limit allowed for an account. Email messages, address books, calendars, tasks, Documents notebook pages and Briefcase files contribute to the quota. Account quotas can be set by COS or per account.

The MTA attempts to deliver a message, and if a Zimbra user’s mailbox exceeds the set quota, the Zimbra mailbox server temporarily sends the message to the deferred queue to be delivered when the mailbox has space. The MTA server’s bounce queue lifetime is set for five days. The deferred queue tries to deliver a message until this bounce queue lifetime is reached before bouncing the message back to the sender. You can change the default through the CLI zmlocalconfig, bounce_queue_lifetime parameter.

Note: To permanently have messages bounced back to the sender, instead

of being sent to the deferred queue first, set the server global config attribute zimbraLmtpPermanentFailureWhenOverQuota to TRUE.

You can view individual account quotas from the Administration Console Monitoring Server Statistics section.

MTA and Amavisd-New Integration

The Amavisd-New utility is the interface between the Zimbra MTA and Clam AV and SpamAssassin scanners.

Anti-Virus Protection

Clam AntiVirus software is bundled with the Zimbra Collaboration Suite as the virus protection engine. The Clam anti-virus software is configured to block encrypted archives, to send notification to administrators when a virus has been found, and to send notification to recipients alerting that a mail message with a virus was not delivered.

The anti-virus protection is enabled for each server during installation. By default, the Zimbra MTA checks every two hours for any new anti-virus updates from ClamAV.

Note: Updates are obtained via HTTP from the ClamAV website.

Anti-Spam Protection

Zimbra utilizes SpamAssassin to control spam. SpamAssassin uses predefined rules as well as a Bayes database to score messages with a numerical range. Zimbra uses a percentage value to determine "spaminess" based on a SpamAssassin score of 20 as 100%. Any message tagged