New Features ZCS 8.5

New Features in Zimbra Collaboration 8.5

   KB 21149        Last updated on 2017-03-13  

(0 votes)

Bringing to notice some notable new features and functionality released with ZCS 8.5

Store related changes

The changes affect the store stack

Real time attachment scanning for outgoing mail sent via the web client


See Also:

Starting with ZCS 8.5, it is possible to enable real-time scanning of attachments in outgoing emails sent via the web client. If enabled, when someone adds an attachment to an email, it will be scanned via ClamAV prior to being able to send the message. If ClamAV detects a virus, it will block attaching the file to the message. By default, scanning is configured for a single node installation. To enable in single node:

In ZCS 8.5.x:

zmprov ms zimbraAttachmentsScanURL clam://localhost:3310/
zmprov mcf zimbraAttachmentsScanEnabled TRUE

In ZCS 8.6.x and later, it is possible to enable/disable attachment scanning globally or per server.

To enable in a multi-node environment, We now support using multiple MTAs for scanning. zimbraClamAVBindAddress is set *per server* on the MTA nodes. It tells the clamav process what hostname to bind to.

zmprov ms <mta server> zimbraClamAVBindAddress <mta server>
zmprov ms <store server> zimbraAttachmentsScanURL clam://<mta server>:3310/
zmprov ms <store server> zimbraAttachmentsScanEnabled TRUE

MTA related changes

These changes affect the MTA stack, which consists of Postfix, Amavis, Cluebringer (cbpolicyd), SpamAssassin, OpenDKIM, Zimbra policy server, ClamAV, DSPAM, DNS caching, Exchange compatible journaling, and the Zimbra Milter.

Key migrations from localconfig to LDAP


Starting with ZCS 8.5, almost every single attribute related to MTA tuning that was store in localconfig is now stored in the LDAP server. By moving attributes out of localconfig and into LDAP, it is now much simpler to configure groups of MTAs in the same fashion, as these settings are nearly always the same between all systems. In this way, the settings can be made at the globalconfig level rather than at the server level, and apply to all MTAs.

Listing the attributes, please refer or see Postconf_keys for which postconf attribute this would set -


DNS caching service


Starting with ZCS8.5 and later, there is now a DNS caching service available for installation. It is specifically targeted for MTA nodes, but could be useful on any node. Three of our supported features rely heavily on DNS lookups:

  1. DKIM verification
  2. SpamAssassin Scoring
  3. Postfix RBLs for spam blocking

However, remote sites that provide the SpamAssassin scoring and Postfix RBLs do *not* like heavy DNS traffic overloading their servers for some reason. Prolonged over-use of their DNS systems will in fact get your MTAs blacklisted from using those services, severely reducing the effectiveness of said services. To ensure our clients do not have their MTAs blacklisted the DNS caching package is now part of ZCS. General setup:

  • Answer [Y] to install zimbra-dnscache
  • When prompted, list the IP(s) of the sites local DNS servers

The installer will automatically reconfigure the DNS cache as the primary resolver for the OS.

NOTE: SHOULD NOT BE INSTALLED ON SYSTEMS THAT ALREADY HAVE BIND OR OTHER DNS SERVICES INSTALLED. Instead, the client should configure such servers to also act as a DNS cache.

Exchange compatible journaling


Starting with ZCS 8.5, it is possible to create a journal for all messages entering or leaving the MTAs that will be delivered to a specific address.

NOTE: Enabling postjournal disables DKIM signing AND origination tagging.

As messages are delivered (internal, inbound or outbound) a transcript of the message (“journal report”) will be created for delivery to an SMTP address. A single journal report will be created for each message delivered – regardless of the number of recipients or routing logic. The journal report is a plain text format message containing a message body with metadata about the actual sender/recipients. It features the original message as an attached EML file (to ensure that all metadata is preserved). The journal report body will match the Exchange journal report format as outlined at:

1) set localconfig as follows:
postjournal_archive_bounce_to = <>
postjournal_archive_rcpt_to = <>
postjournal_enabled = true
postjournal_helo_name = localhost
postjournal_per_user_journaling = 1
postjournal_smtp_read_timeout = 60
postjournal_strip_postfix_proxy = 1
2) zmcontrol restart
3) manually create /opt/zimbra/data/postfix-journal if not created

Features affecting Postfix

The following features have been added in JP affecting Postfix. Postfix is the primary Mail Transport Agent for the ZCS product.

LMDB as the supported backend for on-disk database maps


Starting with ZCS8.5 and later, Postfix is linked to LMDB, the same backend we use with OpenLDAP. Prior to ZCS 8.0, Postfix was linked to Berkeley DB.

Upgrade considerations

ZCS has never officially supported using any postfix on-disk database maps prior to ZCS 8.5. However, many clients have used them via custom non-preserved modifications to the postconf configuration. As usual, these modifications will be lost on upgrade. In addition, to restore the modifications post-upgrade, they will also need to:

  1. Run postmap against the database input file to generate an LMDB database
  2. use lmdb: format instead of hash: format for their modifications

It is worthwhile noting that many of the previously unsupported features that required the use of on-disk database maps are now fully supported, so they will also want to check if this is the case, so that their customizations are correctly carried forward across upgrades.

Ability to blacklist specific IP addresses


Starting with ZCS 8.5 and later, it is now possible to maintain an IP blacklist for connections to Postfix. This is useful in DOS and targeted spam attack scenarios.

Edit /opt/zimbra/conf/postfix_blacklist
Add IP address SPACE REJECT to the file, one IP address per line
postmap /opt/zimbra/conf/postfix_blacklist
zmprov mcf +zimbraMtaRestriction 'check_client_access lmdb:/opt/zimbra/conf/postfix_blacklist

postmap will need to be re-run on the file anytime an IP address is added or removed.

Split Domain support

Reference: &

[zimbra@zqa-148 ~]$ zmprov mcf +zimbraMtaRestriction "check_recipient_access ldap:/opt/zimbra/conf/"
[zimbra@zqa-148 ~]$ zmprov mcf +zimbraMtaRestriction reject

Ability to whitelist blacklisted IP addresses


See also:

Many clients use RBLs to block spammers from flooding their MTAs with spam. Unfortunately perfectly valid sites occasionally end up on these lists. It is now possible with ZCS 8.5 and later to create an on-disk database map that allows the client to whitelist specific blacklisted IPs so that emails from those IPs still get delivered.

Edit /opt/zimbra/conf/postfix_rbl_override
Add IP address(es) SPACE OK to the file, one IP address per line
* OK
postmap /opt/zimbra/conf/postfix_rbl_override
zmprov mcf +zimbraMtaRestriction 'check_client_access lmdb:/opt/zimbra/conf/postfix_rbl_override'

postmap will need to be re-run on the file anytime an IP address is added or removed.

Ability to reject or accept deny emails for specific users


Starting with ZCS 8.5, it is possible to configure postfix to deny or accept specific emails for a given user address, IP address, etc.. This can be used to effectively block spammers targeting a given user, or coming in from a specific IP.

$ vi /opt/zimbra/conf/postfix_recipient_access 550 User Unknown OK OK 550 User Unknown
postmap /opt/zimbra/conf/postfix_recipient_access
zmprov mcf +zimbraMtaRestriction 'check_recipient_access lmdb:/opt/zimbra/conf/postfix_recipient_access'

Ability to configure smtp_generic_maps


Starting with ZCS 8.5, it is possible to configure postfix to preserve the value for smtp_generic_maps across upgrades. This may be used to handle how subdomain routing is done for users.

Ability to reject mail where authenticated user and sender do not match


Starting with ZCS 8.5, it is possible to configure postfix to reject emails where the authenticated user address does not match the From: header of the email. This is primarily to prevent spammers who obtain a user's password from sending out email with different From addresses as they tend to do.

How-to -

postfix-logwatch utility


Starting with ZCS 8.5 and later, two new utilities (amavis-logwatch and postfix-logwatch) will be included with the MTA package with ZCS. These utilities generate extremely useful statistical information about how the MTA is performing and what issue(s) it is encountering. They will likely be added to the Daily Report as well.

root@zqa-062:~# /opt/zimbra/bin/postfix-logwatch /var/log/zimbra.log
****** Summary  *************************************************************************************
      3   *Fatal:   General fatal 
      1   Miscellaneous warnings  
   8.771M  Bytes accepted                           9,196,771
   5.929M  Bytes sent via SMTP                      6,216,580
   3.300M  Bytes sent via LMTP                      3,460,739
========   ==================================================
   1123   Accepted                                   100.00%
--------   --------------------------------------------------
   1123   Total                                      100.00%
========   ==================================================
   1047   Connections             
     15   Connections lost (inbound) 
   1039   Disconnections          
   1125   Removed from queue      
    822   Sent via SMTP           
    429   Sent via LMTP 

Ability to configure cipher strength for smtp and stmpd daemons


Starting with ZCS 8.5, it is possible to configure the TLS related strength factors for postfix to not only enforce encryption but to enforce a certain strength of encryption. To this end multiple LDAP attributes were added:


Documentation for the implications of these attributes can be found at:

Ability to preserve PCI compliance


With ZCS 8.5 and later, it is now possible to preserve PCI compliance configuration across upgrades.

[zimbra@zqa-148 ~]$ zmprov mcf zimbraMtaSmtpdTlsProtocols 'SSLv3,TLSv1,!SSLv2'
[zimbra@zqa-148 ~]$ zmprov mcf zimbraMtaSmtpdTlsExcludeCiphers 'aNULL,MD5,DES'

Features affecting Amavis

The following features have been added in JP affecting Amavis. Amavis provides several features for the ZCS product:

  • Spam scanning (via SpamAssassin)
  • Virus scanning (via ClamAV)
  • Disclaimer support (via altermime)
  • Archiving support

Amavis as a service

References: and

Traditionally, Amavis has only run if one of antispam or antivirus is enabled. Unfortunately, this causes severe problems for customers who do not wish to use our AV/AS offerings, but do want to use disclaimers or archiving. In the past, they've had to keep one of AS/AV enabled to do this. Starting with ZCS 8.0.8 or later, Amavis is now its own service separate from AS/AV. This means it is possible to disable AS/AV support and keep disclaimer and archiving support. For customers who do not wish to run any of these services, it is possible to disable all of them.

Command line active monitoring of Amavis


Command line monitoring of the active amavis processes now exists. As the zimbra user on an MTA running amavis, it is possible to execute a process that indicates what the active amavis processes are doing:

  • /opt/zimbra/amavisd/sbin/amavisd-status

Output is text based:

PID 53071: 53071-20      0:00:00 S
PID 56958: A             0:00:00 A
2 active, 8 idling processes

Adding -h to the command outputs the meaning of the various possible codes:

./amavisd/sbin/amavisd-status -h
States legend:
 A  accepted a connection
 b  begin with a protocol for accepting a request
 m  'MAIL FROM' smtp command started a new transaction in the same session
 d  transferring data from MTA to amavisd
 =  content checking just started
 G  generating and verifying unique mail_id
 D  decoding of mail parts
 V  virus scanning
 S  spam scanning
 P  pen pals database lookup and updates
 r  preparing results
 Q  quarantining and preparing/sending notifications
 F  forwarding mail to MTA
 .  content checking just finished
 sp space indicates idle (elapsed time bar is showing dots)

amavisd-status has two command options:

  • -c how many times to check the status (default: forever)
  • -w how long to wait between checks (default: 1 second)
Usage: ./amavisd/sbin/amavisd-status [-c <count>] [-w <wait-interval>]

Allow Spam preservation regardless of scoring


Some countries and companies have requirements that all email be preserved, regardless of how high the spam score is, but still want spam scoring to occur. To meet this request, we now allow end users to configure what happens to spam that exceeds the threshold for preservation. This is stored in the zimbraAmavisFinalSpamDestiny globalConfig/server LDAP attribute. The default action is D_DISCARD, which drops spam exceeding the threshold rather than delivering it.

Valid values are:

D_PASS -> Deliver all spam regardless of score
D_BOUNCE -> Generate a bounce message
D_REJECT -> Reject the message
D_DISCARD -> (default) Silently discard the message
zmprov mcf zimbraAmavisFinalSpamDestiny D_PASS 
zmprov ms <mta server> zimbraAmavisFinalSpamDestiny D_PASS 

Domain level disclaimer support


In ZCS8.0 and previous, ZCS only supported having a single, global disclaimer that was attached to all emails, regardless of the number of domains on the installation. Starting with ZCS 8.5, we now allow per-domain global disclaimers. This meets critical needs of our hosting providers to allow different disclaimers based on the domains they have on their systems.

See - ZCS 8.5 Admin Guide > Enabling Support for Domain Disclaimers

Upgrade considerations

To handle the change from global to domain specific disclaimers, when a system is upgraded, the global disclaimer will be attached to all existing domains in the installation. This way there is no change in behavior post-upgrade. Once the upgrade is complete, the client can modify the new domain level disclaimers as they see fit. There is no option any longer to have a global disclaimer.

Enabling disclaimer support

This enables the use of disclaimers *at all*. If this is not done, no disclaimers will be attached to emails, regardless of whether or not a domain has a disclaimer associated with it. I.e., it is the global on/off switch

zmprov mcf zimbraDomainMandatoryMailSignatureEnabled TRUE

Adding a disclaimer to a domain

Adding disclaimers to a domain takes multiple steps. The first step is to add the disclaimer text into the LDAP server:

Plain-Text Example

zmprov md zimbraAmavisDomainDisclaimerText "text disclamer"  

HTML Example

zmprov md zimbraAmavisDomainDisclaimerHTML "<html><body>

HTML Disclaimer

User 1

phone number here</body></html>"

After the disclaimer text is added to the LDAP server, disclaimers for the specific domain must be enabled, and then all MTAs updated to grab the disclaimer text. On the first MTA, as the zimbra user:

./libexec/zmaltermimeconfig -e

On all additional MTAs:

To remove a disclaimer from a domain

Removing a disclaimer for a domain that currently has it enabled takes multiple steps.

On the first MTA, as the Zimbra user:

./libexec/zmaltermimeconfig -d <domain>

On all additional MTAs:

Completely disable the disclaimer feature

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

zmprov mcf zimbraDomainMandatoryMailSignatureEnabled FALSE

Disable disclaimers for intra-domain emails


Starting with ZCS 8.5, it is now possible to make it so that emails between individuals in the same domain do not have the disclaimer attached. This is done via the zimbraAmavisOutboundDisclaimersOnly attribute. To preserve backwards compatibility it defaults to FALSE.

Set the Amavis Log level

Reference: See Also:

Starting with ZCS 8.0.5 and later, it is possible to set the Amavis log level. This can be extremely useful for a number of things, such as determining how a particular email got scored the way it did. It is possible to to generate extremely useful timing data with the amavis-logwatch utility at a log level of 2 as well.

zmprov mcf zimbraAmavisLogLevel 2
zmprov ms <mta server> zimbraAmavisLogLevel 2

Set the Amavis SpamAssassin Log level


Starting with ZCS 8.5 and later, it is possible to set the level of logging that SpamAssassin should use via the Amavis configuration. This is set with the attribute zimbraAmavisSALogLevel.

Possible values:

0 -> default, "info" level logging
1 -> all possible logging for SpamAssassin
zmprov mcf zimbraAmavisSALogLevel 1
zmprov ms <mta server> zimbraAmavisSALogLevel 1

amavis-logwatch utility


Starting with ZCS 8.5 and later, two new utilities (amavis-logwatch and postfix-logwatch) will be included with the MTA package with ZCS. These utilities generate extremely useful statistical information about how the MTA is performing and what issue(s) it is encountering. They will likely be added to the Daily Report as well.

root@zqa-062:~# /opt/zimbra/bin/amavis-logwatch /var/log/zimbra.log
****** Summary  *************************************************************************************
    722   Total messages scanned ------------------  100.00%
  5.596M  Total bytes scanned                      5,867,689
========   ==================================================
      1   Blocked ---------------------------------    0.14%
      1     Malware blocked                            0.14%
    721   Passed ----------------------------------   99.86%
    721     Clean passed                              99.86%
========   ==================================================
      1   Malware ---------------------------------    0.14%
      1     Malware blocked                            0.14%
    721   Ham -------------------------------------   99.86%
    721     Clean passed                              99.86%
========   ==================================================
    326   SpamAssassin bypassed   
    531   Extra code modules loaded at runtime 
****** Detail (10)  *********************************************************************************
      1   Malware blocked ----------------------------------------------------------

DKIM verification inside of Amavis can be disabled

Reference: and

Starting with ZC 8.5 and later, it is possible to disable DKIM verification inside of Amavis. This is done via the zimbraAmavisEnableDKIMVerification LDAP attribute, which is globalConfig, server applicable.

To disable -

zmprov mcf zimbraAmavisEnableDKIMVerification FALSE
zmprov <mta server> zimbraAmavisEnableDKIMVerification  FALSE

Amavis/ClamAV concurrency


Starting with ZCS 8.5 and later, it is now possible to adjust the number of processes (concurrency) that are spawned by Amavis, ClamAV, and Postfix. There are two LDAP variables involved, zimbraAmavisMaxServers and zimbraClamAVMaxThreads. These values default to 10, and should always equal one another. I.e., there should be a 1:1 relation between the number of Amavis Servers and ClamAV threads. Having more ClamAV threads than Amavis servers is ok.

To adjust:

zmprov mcf zimbraAmavisMaxServers 8 zimbraClamAVMaxThreads 8
zmprov ms <server> zimbraAmavisMaxServers 8 zimbraClamAVMaxThreads 8

SpamAssassin layout updated


Starting with ZCS 8.5 and later, the layout for SpamAssassin meets the guidelines as set forth by the SpamAssassin developers. SpamAssassin is designed to have 3 working directories. Prior to ZCS 8.5, we wedged them all into one, and then semi-wedged in another one via Amavis. This has been corrected for ZCS 8.5 and later, so that there is no customization necessary via Amavis, and the 3 SpamAssassin directories are correctly created and built out. They are:

  • /opt/zimbra/data/spamassassin/localrules -> This directory contains the *.pre files and local customizations (,
  • /opt/zimbra/data/spamassassin/rules -> This directory contains the default ruleset we ship with ZCS
  • /opt/zimbra/data/spamassassin/state -> This directory contains SpamAssassin rule updates and compiled rules

SpamAssassin compiled rules

Reference: See Also:

Starting with ZCS 8.5 and later, we ship a utility named zmsacompile that is a wrapper for sa-compile. It allows the compilation of SpamAssassin rules. You can also make it so that any new rulesets that are downloaded via zmsaupdate are also automatically compiled. Compiling SpamAssassin rules can significantly decrease the amount of time it takes to process them, speeding up spam scoring and mail deliver. Automatic compilation is controlled with the antispam_enable_rule_compilation localconfig key

General changes not specifically related to a service

The following changes are general and do not apply to a specific service

Upgrade blocking


Starting with ZCS 8.5 and later, upgrades in a multi-node environment will be blocked if the LDAP master has not yet been upgraded to the ZCS version being installed. This will prevent out of order node upgrades, which have caused problems in the past. In addition, it allows the proxy server to correctly handle traffic between upgraded and non-upgraded store servers.

SSL Cert requests should use SHA 256 signatures


To enhance security, the default signature of cert requests is now 256 bits.

Proxy/Memcached packages default to YES for new installations


Starting with ZCS 8.5, the installer prompts to include proxy/memcached on installation. We have new features that heavily rely on both of these products. For example, the mailbox store will now use memached if it is available. Generally expectation is that ALL clients should have at least one proxy/memcached node. 2 or more nodes is required for AlwaysOn.

OracleJDK replaced with OpenJDK (and upgraded to version 8)


Starting with ZCS 8.5 and later, we have moved from using the Oracle provided JDK builds to our own build of OpenJDK. OpenJDK has significantly friendlier license terms for our product, and has evolved to the point where Oracle builds their JDK from OpenJDK and then removes features. In this way, we get the full OpenJDK feature set and are free of Oracle's restrictions. In addition, we are now running version 8 of the JDK.

MySQL replaced with MariaDB


Starting with ZCS 8.5 and later, MySQL has been replaced with MariaDB. This was due to a number of factors, including:

  • Oracle's loss of MySQL developers
  • Oracle's attempts to close source as much of MySQL as possible
  • Better performance from MariaDB
  • Better development team for MariaDB
  • Better response time for issues raised with MariaDB

Background: Back in 2008, Sun Microsystems acquired MySQL. This was a happy union between two major technology firms both dedicated to Open Source principles. Unfortunately just a few years later in 2010, Oracle purchased Sun Microsystems. At that time, the primary developers of MySQL tried to negotiate a spin off for the MySQL product. Oracle was against this. Due to this conflict, the majority of the original MySQL developers quit Oracle once their one year servitude contract was complete. The developers split into two different companies (Monty Program AB and SkySQL). Monty Program AB forked MySQL into MariaDB, and SkySQL sold support for both MySQL and MariaDB. In 2013, the two companies merged into a single company promoting MariaDB (

In essence, MariaDB is the *true* MySQL software as it is developed by over 90% of the original MySQL developers, including the founder (Monty).

innotop and mytop

Reference: and

Starting with ZCS 8.5 and later, two new "top" like utilities for MariaDB are included. These utilities allow real-time monitoring of the SQL DB performance and can be useful in helping to resolve support issues related to the SQL DB. See for usage and output.

Innotop website:

Verified Against: Zimbra Collaboration 8.5 Date Created: 08/16/2014
Article ID: Date Modified: 2017-03-13

Try Zimbra

Try Zimbra Collaboration with a 60-day free trial.
Get it now »

Want to get involved?

You can contribute in the Community, Wiki, Code, or development of Zimlets.
Find out more. »

Looking for a Video?

Visit our YouTube channel to get the latest webinars, technology news, product overviews, and so much more.
Go to the YouTube channel »

Jump to: navigation, search