New Features ZCS 8.5
Bringing to notice some notable new features and functionality released with ZCS 8.5
The changes affect the store stack
Real time attachment scanning for outgoing mail sent via the web client
Reference: https://bugzilla.zimbra.com/show_bug.cgi?id=79231
See Also: https://bugzilla.zimbra.com/show_bug.cgi?id=90188
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:
zmprov ms serverhostname.com zimbraAttachmentsScanURL clam://localhost:3310/ zmprov ms serverhostname.com zimbraAttachmentsScanEnabled TRUE
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 <mta server> zimbraAttachmentsScanURL clam://<mta server>:3310/ zmprov ms <mta server> zimbraAttachmentsScanEnabled TRUE
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
Reference: https://bugzilla.zimbra.com/show_bug.cgi?id=82888
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 zmconfigd.cf or see Postconf_keys for which postconf attribute this would set -
zimbraMtaBlockedExtension zimbraMtaMyNetworks zimbraMtaMaxMessageSize zimbraMtaMyNetworks zimbraMtaAntiSpamLockMethod zimbraMtaEnableSmtpdPolicyd zimbraMtaRestriction zimbraMtaFallbackRelayHost zimbraMtaAuthEnabled zimbraMtaBlockedExtension zimbraMtaRecipientDelimiter zimbraMtaMyNetworks zimbraMtaMyOrigin zimbraMtaMyHostname zimbraMtaSmtpdMilters zimbraMtaNonSmtpdMilters zimbraMtaEnableSmtpdPolicyd zimbraMtaPolicyTimeLimit zimbraMtaEnableSmtpdPolicyd zimbraMtaMyNetworks zimbraMtaMyNetworks zimbraMtaMyOrigin zimbraMtaMyOrigin zimbraMtaMyDestination zimbraMtaMyDestination zimbraMtaSmtpdMilters zimbraMtaSmtpdMilters zimbraMtaNonSmtpdMilters zimbraMtaNonSmtpdMilters zimbraMtaMyHostname zimbraMtaMyHostname zimbraMtaRecipientDelimiter zimbraMtaSaslAuthEnable zimbraMtaDnsLookupsEnabled zimbraMtaMaxMessageSize zimbraMtaMaxUse zimbraMtaRelayHost zimbraMtaFallbackRelayHost zimbraMtaSmtpGenericMaps zimbraMtaAliasMaps zimbraMtaBrokenSaslAuthClients zimbraMtaBounceQueueLifetime zimbraMtaBounceNoticeRecipient zimbraMtaCommandDirectory zimbraMtaDaemonDirectory zimbraMtaDelayWarningTime zimbraMtaDefaultProcessLimit zimbraMtaLmdbMapSize zimbraMtaHeaderChecks zimbraMtaBlockedExtensionWarnRecipient zimbraMtaMailqPath zimbraMtaManpageDirectory zimbraMtaNewaliasesPath zimbraMtaNotifyClasses zimbraMtaQueueDirectory zimbraMtaSmtpdSaslAuthenticatedHeader zimbraMtaSenderCanonicalMaps zimbraMtaSendmailPath zimbraMtaSmtpdBanner zimbraMtaSmtpdClientRestrictions zimbraMtaSmtpdClientPortLogging zimbraMtaSmtpdDataRestrictions zimbraMtaSmtpdHeloRequired zimbraMtaSmtpdProxyTimeout zimbraMtaSmtpdRejectUnlistedRecipient zimbraMtaSmtpdRejectUnlistedSender zimbraMtaSmtpdTlsAskCcert zimbraMtaTlsAuthOnly zimbraMtaSmtpdTlsCAfile zimbraMtaSmtpdTlsCApath zimbraMtaSmtpdTlsCcertVerifydepth zimbraMtaSmtpdTlsCiphers zimbraMtaSmtpdTlsExcludeCiphers zimbraMtaSmtpdTlsLoglevel zimbraMtaSmtpdTlsMandatoryCiphers zimbraMtaSmtpdTlsProtocols zimbraMtaTlsSecurityLevel zimbraMtaSmtpdErrorSleepTime zimbraMtaSmtpdHardErrorLimit zimbraMtaStpdSoftErrorLimit zimbraMtaInFlowDelay zimbraMtaImportEnvironment zimbraMtaQueueRunDelay zimbraMtaMinimalBackoffTime zimbraMtaMaximalBackoffTime zimbraMtaLmtpConnectionCacheDestinations zimbraMtaLmtpConnectionCacheTimeLimit zimbraMtaLmtpHostLookup zimbraMtaTransportMaps zimbraMtaPropagateUnmatchedExtensions zimbraMtaVirtualAliasDomains zimbraMtaVirtualAliasExpansionLimit zimbraMtaVirtualAliasMaps zimbraMtaVirtualMailboxDomains zimbraMtaVirtualMailboxMaps zimbraMtaSmtpdVirtualTransport zimbraMtaAlwaysAddMissingHeaders zimbraMtaSmtpdSaslSecurityOptions zimbraMtaSmtpdSaslTlsSecurityOptions zimbraMtaSmtpHeloName zimbraMtaSmtpCnameOverridesServername zimbraMtaSmtpSaslAuthEnable zimbraMtaSmtpSaslSecurityOptions zimbraMtaSmtpTlsCAfile zimbraMtaSmtpTlsCApath zimbraMtaTlsAppendDefaultCA zimbraMtaSmtpTlsSecurityLevel zimbraMtaSmtpTlsLoglevel zimbraMtaSmtpTlsCiphers zimbraMtaSmtpTlsMandatoryCiphers zimbraMtaSmtpSaslMechanismFilter zimbraMtaSmtpSaslPasswordMaps zimbraMtaMilterConnectTimeout zimbraMtaMilterCommandTimeout zimbraMtaMilterContentTimeout zimbraMtaMilterDefaultAction zimbraMtaUnverifiedRecipientDeferCode zimbraMtaAddressVerifyPollCount zimbraMtaAddressVerifyPollDelay zimbraMtaAddressVerifyNegativeRefreshTime zimbraMtaAddressVerifyPositiveRefreshTime zimbraMtaMyNetworks zimbraMtaSaslSmtpdMechList
DNS caching service
Reference: https://bugzilla.zimbra.com/show_bug.cgi?id=83670
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:
- DKIM verification
- SpamAssassin Scoring
- 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
Reference: https://bugzilla.zimbra.com/show_bug.cgi?id=70755
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: http://technet.microsoft.com/en-us/library/bb738122(v=EXCHG.80).aspx#Format
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
Reference: https://bugzilla.zimbra.com/show_bug.cgi?id=77586
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:
- Run postmap against the database input file to generate an LMDB database
- 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
Reference: https://bugzilla.zimbra.com/show_bug.cgi?id=90050
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 * 1.2.3.4 REJECT
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: https://bugzilla.zimbra.com/show_bug.cgi?id=83784 & http://wiki.zimbra.com/wiki/Split_Domain#Avoiding_Loops_in_Delivery
[zimbra@zqa-148 ~]$ zmprov mcf +zimbraMtaRestriction "check_recipient_access ldap:/opt/zimbra/conf/ldap-splitdomain.cf" [zimbra@zqa-148 ~]$ zmprov mcf +zimbraMtaRestriction reject
Ability to whitelist blacklisted IP addresses
Reference: https://bugzilla.zimbra.com/show_bug.cgi?id=84275
See also: http://wiki.zimbra.com/wiki/Improving_Anti-spam_system#Postfix_whitelist_when_using_RBL.27s
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 * 1.2.3.4 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
Reference: https://bugzilla.zimbra.com/show_bug.cgi?id=90196
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 qa_test1@zqa-062.eng.vmware.com 550 User Unknown qa_test2@zqa-062.eng.vmware.com OK 10.137.244.61 OK 50.60.70.80 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
Reference: https://bugzilla.zimbra.com/show_bug.cgi?id=93579
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
Reference: https://bugzilla.zimbra.com/show_bug.cgi?id=11258
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 - https://wiki.zimbra.com/wiki/Enforcing_a_match_between_FROM_address_and_sasl_username_8.5
postfix-logwatch utility
Reference: https://bugzilla.zimbra.com/show_bug.cgi?id=89450
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
Reference: https://bugzilla.zimbra.com/show_bug.cgi?id=84123
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:
zimbraMtaSmtpTlsCAfile zimbraMtaSmtpTlsCApath zimbraMtaTlsAppendDefaultCA zimbraMtaSmtpTlsSecurityLevel zimbraMtaSmtpTlsLoglevel zimbraMtaSmtpTlsCiphers zimbraMtaSmtpTlsMandatoryCiphers zimbraMtaSmtpdTlsAskCcert zimbraMtaTlsAuthOnly zimbraMtaSmtpdTlsCAfile zimbraMtaSmtpdTlsCApath zimbraMtaSmtpdTlsCcertVerifydepth zimbraMtaSmtpdTlsCiphers zimbraMtaSmtpdTlsLoglevel zimbraMtaSmtpdTlsMandatoryCiphers zimbraMtaTlsSecurityLevel
Documentation for the implications of these attributes can be found at: http://www.postfix.org/postconf.5.html
Ability to preserve PCI compliance
Reference: https://bugzilla.zimbra.com/show_bug.cgi?id=94122
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: https://bugzilla.zimbra.com/show_bug.cgi?id=67460 and https://bugzilla.zimbra.com/show_bug.cgi?id=89603
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
Reference: https://bugzilla.zimbra.com/show_bug.cgi?id=9855
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
Reference: https://bugzilla.zimbra.com/show_bug.cgi?id=11063
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
Reference: https://bugzilla.zimbra.com/show_bug.cgi?id=41872
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:
zmprov md example.com zimbraAmavisDomainDisclaimerText "text disclamer" zimbraAmavisDomainDisclaimerHTML "HTML disclaimer"
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 example.com
On all additional MTAs:
./libexec/zmaltermimeconfig
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:
./libexec/zmaltermimeconfig
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
Reference: https://bugzilla.zimbra.com/show_bug.cgi?id=44061
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: https://bugzilla.zimbra.com/show_bug.cgi?id=83667 See Also: http://wiki.zimbra.com/wiki/SpamAssassin_Customizations
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 or zmprov ms <mta server> zimbraAmavisLogLevel 2
Set the Amavis SpamAssassin Log level
Reference: https://bugzilla.zimbra.com/show_bug.cgi?id=86816
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 or zmprov ms <mta server> zimbraAmavisSALogLevel 1
amavis-logwatch utility
Reference: https://bugzilla.zimbra.com/show_bug.cgi?id=89450
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: https://bugzilla.zimbra.com/show_bug.cgi?id=76288 and https://bugzilla.zimbra.com/show_bug.cgi?id=76049
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 or zmprov <mta server> zimbraAmavisEnableDKIMVerification FALSE
Amavis/ClamAV concurrency
Reference: https://bugzilla.zimbra.com/show_bug.cgi?id=55637
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 or zmprov ms <server> zimbraAmavisMaxServers 8 zimbraClamAVMaxThreads 8
SpamAssassin layout updated
Reference: https://bugzilla.zimbra.com/show_bug.cgi?id=84582
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 (salocal.cf, sauser.cf)
- /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: https://bugzilla.zimbra.com/show_bug.cgi?id=89734 See Also: https://wiki.zimbra.com/wiki/SpamAssassin_Customizations
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
The following changes are general and do not apply to a specific service
Upgrade blocking
Reference: https://bugzilla.zimbra.com/show_bug.cgi?id=31460
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
Reference: https://bugzilla.zimbra.com/show_bug.cgi?id=86761
To enhance security, the default signature of cert requests is now 256 bits.
Proxy/Memcached packages default to YES for new installations
Reference: https://bugzilla.zimbra.com/show_bug.cgi?id=80280
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)
Reference: https://bugzilla.zimbra.com/show_bug.cgi?id=83787
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
Reference: https://bugzilla.zimbra.com/show_bug.cgi?id=58747
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 (http://techcrunch.com/2013/04/23/skysql-merges-with-mariadb-to-solidify-its-open-source-database-position/).
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: https://bugzilla.zimbra.com/show_bug.cgi?id=66857 and https://bugzilla.zimbra.com/show_bug.cgi?id=88772
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 https://bugzilla.zimbra.com/show_bug.cgi?id=88772#c7 for usage and output.
Innotop website: https://code.google.com/p/innotop/