https://wiki.zimbra.com/api.php?action=feedcontributions&user=Publiski&feedformat=atomZimbra :: Tech Center - User contributions [en]2024-03-29T13:03:56ZUser contributionsMediaWiki 1.39.0https://wiki.zimbra.com/index.php?title=Performance_Tuning_Guidelines_for_Large_Deployments&diff=66186Performance Tuning Guidelines for Large Deployments2019-03-07T14:08:11Z<p>Publiski: /* MariaDB/MySQL */</p>
<hr />
<div>{{BC|Certified}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=Performance Tuning Guidelines for Large Deployments=<br />
{{KB|{{ZC}}|{{ZCS 8.5}}|{{ZCS 8.0}}{{ZCS 7.0}}|}}<br />
=Hardware and Operating System=<br />
<br />
==RAM and CPU==<br />
<br />
ZCS, like all messaging and collaboration systems, is an IO bound application. Three core components of ZCS (a) the Java based message store (aka mailbox server, jetty in ZCS 5.0 onwards, tomcat in 4.5.x and earlier), (b) MariaDB (MySQL prior to ZCS 8.5) instances used for metadata, and (c) LDAP servers (master and replica) - all rely heavily on caching data in RAM to provide better performance and reduce disk IO. For all large installations we recommend at least 8GB of RAM. Our testing shows that a system with the same CPUs and disk is able to support more users when upgraded from 8GB to 16GB of RAM.<br />
<br />
We recommend an x86_64 dual-dual core CPU, of a speed that is not too low or too high on the price/performance ratio. Disable hyper-threading if that feature is present in your CPU (performance monitoring data is unreliable). At this time, we have not tested on dual-quad cores (coming soon).<br />
<br />
Almost all recent 'x86' server CPUs support installing a 32-bit/i686 version of Linux or a 64-bit/x86_64 version. We strongly recommend installing the 64-bit version if you have more than 4GB of RAM. If you have 4GB of RAM or less, it is unclear that the 64-bit version will boost performance, but you shouldn't really be running a large install on a system with < 8GB of RAM. If you anticipate adding more RAM in the near future during a maintenance window, do install the 64-bit version now - upgrade from 32-bit to 64-bit is possible, but a lot of work. In general, we recommend running with a minimum of 8GB of RAM for all nodes, and most sites of high usage run mailstores of at least 16GB of RAM, and often 24GB, 32GB or 64GB for the larger platforms. LDAP nodes with millions of users can require 32-128GB of RAM. <br />
<br />
A word of caution is in order around 32-bit kernel and 8GB of RAM. In 32-bit mode, the CPU can address only 4GB of RAM even if you paid for 8GB worth of memory sticks, and, by default, a 32-bit Linux kernel only allows each process to address 2GB of space. Through PAE (Process Address Extension), a feature available in some CPUs, and a special 32-bit kernel that supports large address space for processes, it is possible to get a 32-bit mode kernel that really uses > 4GB of RAM, and get a per process 3-4GB address range. Please avoid this hassle. Given there is plenty of RAM, the CPU performs better in 64-bit mode, more CPU registers are available, there is no segment addressing overhead introduced by PAE, and you get a tested platform.<br />
<br />
Monitor for swap activity as swapping very adversely affects Zimbra performance. Make sure you have not over-configured memory settings for ZCS components (details in mailbox server section below).<br />
<br />
Consider setting swappiness to 0. You can have it take effect immediately with <tt>sysctl -w</tt>. For a permanent change that takes effect at next reboot, add the following to <tt>/etc/sysctl.conf</tt>:<br />
<br />
vm.swappiness=0<br />
<br />
==Disk==<br />
<br />
Zimbra mailbox servers are read/write intensive, and even with enough RAM/cache, the message store will generate a lot of disk activity. LDAP is read heavy and light on writes, is able to use caches a lot more effectively, and does not generate the type of disk activity that mailbox servers do.<br />
<br />
In a mailbox server, the greatest source IO activity is generated by these three sources, in decreasing order of load generated:<br />
<br />
* Lucene search index managed by the Java mailbox process<br />
* MariaDB/MySQL instance that runs on each message store server, and stores metadata (folders, tags, flags, etc)<br />
* Blob store managed by the Java mailbox process<br />
<br />
MariaDB/MySQL, Lucene and blob stores generate random IO and therefore have to be serviced by a fast disk subsystem. Below are some guidelines around selecting a disk system. Contact pre-sales support for more detailed guidance.<br />
<br />
* '''NO RAID5'''. RAID5 (and similar parity based RAID schemes) give you capacity, but take away IO performance. Do not believe any streaming file IO peak throughput numbers of RAID5 systems, and expect performance when storing a database.<br />
<br />
* '''NO NFS'''. It is our experience that the world is full of poor NFS implementations (server and client), and sometimes the disks backing that NFS mount are not performant to boot. Also note that many upstream OSS components of Zimbra (BDB, OpenLDAP, MySQL, Lucene) have or do discourage the use of NFS to store binary/mmaped data.<br />
<br />
* '''NO SATA'''. SATA drives are great for large capacities and you can even get models with MTBFs that match SCSI and FC drives, but they do not perform as well the 15KRPM or 10KRPM SCSI/FC options. ZCS Network Edition supports Hierarchical Storage Management (HSM) which can be used to store older message blobs on a slightly slower subsystem. You can consider SATA for the HSM destination volume, but make sure that the HSM destination is not so slow that that the HSM processes doesn't complete or takes too long.<br />
<br />
* '''Don't just size for capacity'''. Eg, 2 x 147 GB drives will perform better than 1 x 300 GB drive.<br />
<br />
* '''Use SANs'''. Best disk performance today still comes from large SANs with ton of cache (eg, 32 GB).<br />
<br />
* '''Use NVRAM'''. SANs use some non-volatile RAM to speed up disk writes perform better. In internal disk implementations, some SCSI controllers support a Battery Backup Unit (BBU) to provide this functionality.<br />
<br />
* '''NO Drive Caches'''. Make sure your disk system/controller disables write caching in the drives. Use of write caches at the drive drives could cause permanent and unrecoverable corruption if contents of these caches are lost in a power failure.<br />
<br />
==Services to Disable==<br />
<br />
Linux distributions tend to enable services by default that are not really required in a production ZCS server. We recommend identifying and disabling such services to reduce risk of exposure to vulnerabilities in services that are enabled but not really needed/used, and to avoid any unintended performance interference.<br />
<br />
* Use <tt>chkconfig --list</tt> to get information about services on your system at various boot/run levels.<br />
* Examine the output of <tt>ps -ef</tt> and make sure there are no processes running that shouldn't be.<br />
<br />
The table below lists a few examples of services that may be installed by your Linux distribution that you might consider disabling. Use it as a guide - it is not an exhaustive or prescriptive list. Some services maybe required for the proper functioning of your system, so exercise caution when disabling services.<br />
<br />
* '''autofs, netfs''': Services that make remote filesystem available.<br />
* '''cups''': Print services.<br />
* '''xinetd, vsftpd''': UNIX services (eg, telnet) that may not be required.<br />
* '''nfs, smb, nfslock''': Services that export local filesystems to remote hosts.<br />
* '''portmap, rpcsvcgssd, rpcgssd, rpcidmapd''': UNIX RPC services usually used in conjunction with network file systems.<br />
* '''dovecot, cyrus-imapd, sendmail, exim, postfix, ldap''': Duplicates installed by the distro of functionality or packages provided by ZCS.<br />
* '''slocate/updatedb''': ZCS stores one message per file, and an updatedb crawl every day at 4am can be expensive.<br />
* '''Integrity Report''': zmdbintegrityreport is run on a weekly basis from cron on all zimbra-store nodes. For large sites, you can opt to disable this by setting '''zmlocalconfig -e zmdbintegrityreport_disabled=TRUE'''. If you choose to disable this feature, it is suggested you run the integrity reports manually during their normal maintenance windows and prior to running any upgrades.<br />
<br />
==Services to Enable==<br />
<br />
Certain services are either required or useful when running ZCS:<br />
<br />
* '''sshd''': Secure SHell remote login service is required by ZCS tools. Also used by administrator (ie, people) login to the server. Consider disabling root login and password authentication.</tt><br />
* '''syslog''': Handles logging of system events. On a multi-node install, designate a single/dedicated server for running syslog server. Logs are auto-rotated and will not fill your hard drive. For rsyslog, if there is heaving logging on your server, something like the following may be put in rsyslog.conf to avoid rate limiting:<br />
$SystemLogRateLimitInterval 0<br />
$SystemLogRateLimitBurst 0<br />
* '''sysstat''': System performance monitoring tools for Linux. Includes <tt>iostat</tt>, which is required by the ZCS <tt>zmstats</tt> service.<br />
* '''ntpd''': Network Time Protocol server that adjusts for drifts in your system clock.<br />
<br />
==Diagnostic Tools==<br />
<br />
Please install and be familiar with the use of at least the following operating system monitoring tools.<br />
<br />
* '''lsof''': Show files and network connections in use.<br />
* '''tcpdump''': Sniff network traffic.<br />
* '''iostat''': Monitor IO statistics. <tt>-x</tt> option is particularly useful.<br />
* '''vmstat''': Monitor CPU/memory use.<br />
* '''pstack''': Get stack trace from a running process (for a Java process a JVM generated thread dump is usually more interesting.) <br />
* '''strace''': Trace systems calls.<br />
<br />
Some of these tools are part of the <tt>'''procps'''</tt> and <tt>'''sysstat'''</tt> packages.<br />
<br />
The <tt>zmstat</tt> service shipped since ZCS 4.5.9 requires atleast the IO/CPU/memory monitoring tools to record performance data periodically. It is a good idea to make sure all your servers have the 'zmstats' service enabled.<br />
<br />
==Open File Descriptors Limit==<br />
<br />
The mailbox server (specially the Lucene search index) might need to operate on a large number of files at the same time. The Zimbra installer modifies /etc/security/limits.conf to set the maximum number of file descriptors that the 'zimbra' UNIX user is allowed to concurrently open. Until ZCS 5.0.2, the installer used to set this limit to 10,000, and this wiki page used to advice that large installs modify this to 100,000.<br />
<br />
As of ZCS 5.0.2, the installer sets the max file descriptor limit to 524,288 (2^19). See bug 23211 for details. Installations upgrading from earlier releases of ZCS should verify that their /etc/security/limits.conf contains the following lines after the upgrade to ZCS 5.0.2:<br />
<br />
zimbra soft nofile 524288<br />
zimbra hard nofile 524288<br />
<br />
==File System==<br />
<br />
We recommend the '''ext3''' or '''ext4''' file system for Linux deployments (tried and true, performance for random IO is a wash, gains only in blob store for other file systems). <br />
<br />
Mount your file systems with the '''noatime''' option. By default, the '''atime''' option is enabled and updates the last access time data for files. Mounting your file systems with the noatime option reduces write load on the disk subsystem.<br />
<br />
You should enable '''dirsync''' for ext3/ext4 file systems (or equivalent method for a non-ext3/non-ext4 file system). Zimbra mailbox server uses fsync(2) as necessary to ensure that data in files are flushed from buffers to disk. Eg, when an incoming message is received, fsync is called on the blob store message file before the MTA is given an acknowledgment that the message was received/delivered by the MBS. However, when Zimbra mailbox server or MTA creates new files, such as during message delivery, the update to the directory containing the file must be flushed to disk. Even if the data in the file is flushed with fsync, the file entry in the directory might be lost if server crashes before the directory update is flushed to disk. With the ext3/ext4 file system, to have directory updates be written to disk automatically and atomically, you can update directory attributes by running <tt>chattr +D dir</tt> on all the relevant directories. If you are doing this for the first time, you should consider running <tt>chattr -R +D</tt> to recursively update a whole tree of directories; future sub-directories will inherit the attribute from parent directory. We recommend dirsync be enabled for all blob stores, Lucene search index directories, and MTA queues. With the ext3/xt4 file system, you can also add <tt>dirsync</tt> as a mount option, but you will have to exercise caution to not enable this on the root filesystem - we've received reports of the boot loader failing in the presence of dirsync as a mount option on the root file system.<br />
<br />
We suggest the following options as a guideline for when creating an ext3 or ext4 file system with the <tt>mke2fs</tt> command. Consult ext3 documentation.<br />
<br />
'''''Caution''': Running mke2Fs will wipe '''all''' data from the partition. Make sure that you create the file system in the correct partition.''<br />
<br />
{| width="80%" border="1" cellpadding="4" cellspacing="0"<br />
| width="15%" valign="top" |<tt>'''-j'''</tt><br />
| valign="top" |Create the file system with an ext3/ext4 journal.<br />
|-<br />
| valign="top" |<tt>'''-L SOME_LABEL'''</tt><br />
| valign="top" |Create a new volume label. Refer to the labels in <tt>/etc/fstab</tt><br />
|-<br />
| valign="top" |<tt>'''-O dir_index'''</tt><br />
| valign="top" |Use hashed b-trees to speed up lookups in large directories.<br />
|-<br />
| valign="top" |<tt>'''-m 2'''</tt><br />
| valign="top" |Only 2% needs to be reserved for root on large filesystems.<br />
|-<br />
| valign="top" |<tt>'''-i 10240'''</tt><br />
| valign="top" |For message store, option -i should be the expected average message size. Estimate this conservatively, as no. of inodes can not be changed after creation.<br />
|-<br />
| valign="top" |<tt>'''-J size=400'''</tt><br />
| valign="top" |Create a large journal.<br />
|-<br />
| valign="top" |<tt>'''-b 4096'''</tt><br />
| valign="top" |Block size in bytes.<br />
|-<br />
| valign="top" |<tt>'''-R stride=16'''</tt><br />
| valign="top" |Stride is used to tell the file system about the size of the RAID configuration. Stride * block size should be equal to RAID stripe size. For example 4k blocks, 128k RAID stripes would set stride=32.<br />
|}<br />
<br />
==Network Ports==<br />
<br />
Perform a portscan of your servers from a remote host and localhost (eg, use <tt>nmap</tt>). Only ports that you need to have open should be open.<br />
<br />
The following ports are used by ZCS. If you have any other services running on these ports, turn them off.<br />
<br />
{|border="1" cellpadding="4" cellspacing="0"<br />
|valign="middle" |'''Port'''<br />
|valign="middle"|'''ZCS Service'''<br />
|-<br />
|valign="top" |25<br />
|valign="top" |Postfix<br />
|-<br />
| valign="top" |80<br />
|valign="top" |HTTP<br />
|-<br />
| valign="top" |110<br />
| valign="top" |POP3<br />
|-<br />
| valign="top" |143<br />
| valign="top" |IMAP<br />
|-<br />
| valign="top" |389<br />
| valign="top" |LDAP<br />
|-<br />
| valign="top" |443<br />
| valign="top" |HTTPS<br />
|-<br />
| valign="top" |587<br />
| valign="top" |SMTP MSA (Message Submission RFC 6409)<br />
|-<br />
| valign="top" |993<br />
| valign="top" |IMAP SSL<br />
|-<br />
| valign="top" |995<br />
| valign="top" |POP3 SSL<br />
|-<br />
| valign="top" |5222<br />
| valign="top" |XMPP client connection (removed: ZCS 8)<br />
|-<br />
| valign="top" |5223<br />
| valign="top" |XMPP client connection over SSL (removed: ZCS 8)<br />
|-<br />
| valign="top" |5269<br />
| valign="top" |XMPP server connection (removed: ZCS 8)<br />
|-<br />
| valign="top" |7025<br />
| valign="top" |LMTP<br />
|-<br />
| valign="top" |7047<br />
| valign="top" |Conversion Server (httpd)<br />
|-<br />
| valign="top" |7071<br />
| valign="top" |ZCS Admin services connector (SSL)<br />
|-<br />
| valign="top" |7072<br />
| valign="top" |ZCS Nginx Lookup (backend http service for nginx lookup/authentication)<br />
|-<br />
| valign="top" |7110<br />
| valign="top" |Backend POP3 (if proxy configured)<br />
|-<br />
| valign="top" |7143<br />
| valign="top" |Backend IMAP (if proxy configured)<br />
|-<br />
| valign="top" |7306<br />
| valign="top" |MySQL/MariaDB<br />
|-<br />
| valign="top" |7307<br />
| valign="top" |Logger MySQL (removed: ZCS 7)<br />
|-<br />
| valign="top" |7335<br />
| valign="top" |XMPP intra-cloud routing listener (removed: ZCS 8)<br />
|-<br />
| valign="top" |7777<br />
| valign="top" |XMPP Proxy Service (removed: ZCS 8)<br />
|-<br />
| valign="top" |7993<br />
| valign="top" |Backend IMAP SSL (if proxy configured) (not used with nginx since 5.0?)<br />
|-<br />
| valign="top" |7995<br />
| valign="top" |Backend POP3 SSL (if proxy configured) (not used with nginx since 5.0?)<br />
|-<br />
| valign="top" |10015<br />
| valign="top" |XMPP external component listener (removed: ZCS 8)<br />
|-<br />
| valign="top" |10024<br />
| valign="top" |amavisd-new<br />
|-<br />
| valign="top" |10025<br />
| valign="top" |Postfix answering amavisd-new<br />
|-<br />
| valign="top" |11211<br />
| valign="top" |memcached (nginx route lookups)<br />
|}<br />
<br />
For a multi-server deployment, see also [[Ports]].<br />
<br />
==Network Stack==<br />
<br />
The Linux kernel makes TCP/IP network tunables available in the <tt>/proc/sys/net/ipv4</tt> directory. These files can be modified directly or with the <tt>sysctl</tt> command to make kernel configuration changes on the fly. But changes made this way do '''not''' persist across reboots. We recommend editing the file <tt>/etc/sysctl.conf</tt> and adding the settings below so they will be permanent. If you need your edits to <tt>sysctl.conf</tt> to take effect right away, use the <tt>sysctl -p</tt> option.<br />
<br />
net.ipv4.tcp_fin_timeout=15<br />
net.ipv4.tcp_tw_reuse=1<br />
net.ipv4.tcp_tw_recycle=1<br />
<br />
The above settings allow for ZCS servers to handle a lot of short lived connections. When TCP/IP was designed, networks were lossy and had high latency. With today's modern networks, it is common practice to configure the above options so port numbers are not stuck in <tt>TIME_WAIT</tt> state. Various RFCs specify how long to wait, and even kernel docs caution you against changing the defaults, but it can pay to be aggressive. Documentation for these settings is in the kernel-doc package, in the file <tt>networking/ip-sysctl.txt</tt>.<br />
<br />
Please use these settings carefully. If there are any issues with network connectivity to Zimbra, please obtain a packet capture and revert configuration changes made to the kernel. Also, it may be necessary to update the kernel if issues are persistent.<br />
<br />
=Zimbra Mailbox Server=<br />
<br />
==Connection Handling==<br />
<br />
Each ZCS mailbox server is a HTTP, IMAP and POP3 server, rolled into one process. The server is highly multi-threaded and uses pool of threads to service incoming connections for these services. An important part of connection handling configuration is sizing these thread pools. Moderns JVMs and kernels are able to support a lot of threads (we have tested as high as 3000), however too many threads can cause memory pressure on the server. <br />
<br />
These thread pool sizes can be configured on a per server basis. However, if you have or will have a multi-node install and all your servers will have a similar configuration, you can set the size in global config, so any new servers you add will get the right defaults for your environment. You can always override the global config setting on any server, by setting the value in the server object. We'll identify any attributes that can be set in both global config or server with a comment below, but show the example as modifying server. Use <tt>zmprov modifyServer</tt> to modify server attributes, and <tt>zmprov modifyConfig</tt> to modify global config.<br />
<br />
Add note about server restart. Add note about having to apply this on each server. Both these should be higher level comments, probably along with the global config vs server blurb.<br />
<br />
===HTTP===<br />
<br />
As of ZCS 5.0, the HTTP stack used by the mailbox server is provided by Jetty (a Java application container). Earlier releases used Apache Tomcat. In both cases, a thread is dedicated to the servicing a HTTP request. Jetty also offers support for idle but long lived HTTP connections without a dedicated thread (see [http://www.zimbrablog.com/blog/archives/2007/12/why-we-switched-to-jetty.html Zimbra blog]). Since HTTP connections are not usually long lived, you must size the HTTP thread pool to accommodate concurrent connections at any instant during at the busiest time of the day for the server. You can examine access_log from Jetty or Tomcat to look at your concurrent connections in peak second, and add a 50% padding to that. For most installations, we have found 250 threads each for HTTP and HTTPS to be sufficient.<br />
<br />
# ZCS 5.0 has a single thread pool for both HTTP and HTTPS<br />
# global config or server OK<br />
$ zmprov ms this.server.name zimbraHttpNumThreads 500<br />
<br />
# ZCS 4.5.x and earlier had distinct thread pools for HTTP and HTTPS<br />
# global config or server OK<br />
$ zmprov ms this.server.name zimbraHttpNumThreads 250<br />
$ zmprov ms this.server.name zimbraHttpSSLNumThreads 250<br />
<br />
===POP3===<br />
<br />
POP3 connections are in general short lived like HTTP connections. The size of the POP3 thread pool should be derived similarly, but the log file to use is audit.log. We have found that a setting of 300 is able to support a few 10s of thousands of users logging in and checking mail every 8 minutes. <br />
<br />
# global config or server OK<br />
$ zmprov ms this.server.name zimbraPop3NumThreads 300<br />
<br />
Most POP3 connections do login, download mail, delete downloaded mail on server, logout. Mailboxes are small and contain the most recent mail. POP3 users who use download but keep on server cause higher load on server for large Inbox folders. Users with large mailboxes seldom use POP3, so this is not a common case.<br />
<br />
===IMAP===<br />
<br />
IMAP thread pool sizing is very different from HTTP/POP3 thread pool sizing. IMAP clients connect and leave the connections open for long periods of time. Some IMAP clients create as many as 4 simultaneous connections to the server. IMAP protocol, by nature, also places a lot of load on servers. With IMAP NIO being the default on ZCS8, there is no need to change the zimbraImapNumThreads to support more IMAP connection since a single thread can handle multiple connections. The default value is sufficient for up to 10,000 active IMAP clients. <br />
<br />
The zimbraImapMaxConnections should be set to match the peak number of active IMAP clients. Each client typically opens 3-4 connections, so for 10,000 active clients up to 40,000 connections may be required.<br />
<br />
We recommend closely monitoring your IMAP load and distributing IMAP users across more mailbox servers.<br />
# global config or server OK<br />
$ zmprov ms this.server.name zimbraImapMaxConnections 40000<br />
<br />
You can read more about NIO in the next section - '''[https://wiki.zimbra.com/wiki/Performance_Tuning_Guidelines_for_Large_Deployments#NIO NIO]'''<br />
<br />
===LMTP===<br />
<br />
LMTP is the protocol through which mailbox servers receive messages from the Postfix MTA. When possible, Postfix performs multiple LMTP transactions on the same connection. Message delivery is an expensive operation, so a handful of message delivery threads can keep the server busy, unless the message delivery threads become blocked on some resource. While it is tempting to increase the LMTP threads (and the corresponding Postfix LMTP concurrency setting) when MTA queues are behind and latency on message delivery is high, adding more concurrent load is unlikely to speed delivery - you will likely bottleneck your IO subsystem and risk making throughput lower because of contention. If you do experience mail queue backup because LMTP deliveries are slow, then do thread dumps on the mailbox server to see why the LMTP threads are unable to make progress. Another risk of a high LMTP concurrency is that is the event there is a bulk mailing, the server may become unresponsive because it is so busy with message deliveries. The default postfix LMTP concurrency and mailbox server LMTP threads is 20. <br />
<br />
# global config or server OK<br />
$ zmprov ms <localservername> zimbraLmtpNumThreads 40<br />
<br />
# on each MTA server...<br />
$ zmlocalconfig -e postfix_lmtp_destination_concurrency_limit=20<br />
<br />
===NIO===<br />
<br />
<br />
As of ZCS 8, we have enabled NIO for IMAP and POP:<br />
<br />
* IMAP/POP NIO Server GA [http://bugzilla.zimbra.com/show_bug.cgi?id=9470] - Fixed: 8.0<br />
<br />
The basic functionality is managed by the following LC values:<br />
<br />
nio_imap_enabled = true<br />
nio_pop3_enabled = true<br />
<br />
The default NIO options should work well most of the time. We did, however, fix a few serious issues in later 8.0.x versions:<br />
<br />
* NIO IMAP incorrectly processes requests in case of "maximum literal size exceeded" [http://bugzilla.zimbra.com/show_bug.cgi?id=77275] - Fixed: 8.0.2<br />
* ImapServer does not start when NIO enabled and zimbraMtaMaxMessageSize set to 0 [http://bugzilla.zimbra.com/show_bug.cgi?id=79003] - Fixed: 8.0.3<br />
* NIO imap, NIOSocketSession leaking [http://bugzilla.zimbra.com/show_bug.cgi?id=80878] - Fixed: 8.0.4 Patch, 8.0.5<br />
<br />
Before ZCS used NIO, we required at more zimbraImapNumThreads [(# of Imap Users) * (# of connection/IMAP user) = zimbraImapNumThreads] because physical connection of the IMAP user and ImapThread is 1:1 mapping.<br />
With NIO, one thread can handle multiple physical connections (m:n mapping).<br />
<br />
So, a default of zimbraImapNumThreads (100) can handle perhaps 2000-5000 IMAP users if those uses didn't create 100 concurrency at any moment. (Similar to Jetty NIO, where we have 250 HTTP threads but we can support 2000-5000 HTTP users under normal conditions. If we really see 100 concurrent active HTTP or IMAP threads in any thread dump, it means the server is slow and most likely, the slowness is not caused by # of threads.) We don't need to worry if 100 is too many threads either, because the server connection pool will reap the idle ones if they are really idle. <br />
<br />
ZCS has another parameter zimbraImapMaxConnections (default: 200) - it is associated with zimbraImapNumThreads and is the # of any concurrent active connections).<br />
<br />
When we should change the default value:<br />
<br />
* zimbraImapMaxConnections or zimbraPop3MaxConnections: if you see "Dropping connection (max connections exceeded)" in server log. <br />
* zimbraImapNumThreads or zimbraPop3NumThreads: if you see more than $zimbraImapNumThreads imap threads are active in the thread dump and no more IMAP users are able to connect to the server. Again though, you can tune up this value, but they are most likely just symptoms of a slow server, not root cause.<br />
<br />
<pre><br />
<br />
<attr id="1155" name="zimbraPop3MaxConnections" type="integer" cardinality="single" optionalIn="globalConfig,server" flags="serverInherited" requiresRestart="mailbox" since="8.0.0"><br />
<globalConfigValue>200</globalConfigValue><br />
<desc>Maximum number of concurrent POP3 connections allowed. New connections exceeding this limit are rejected.</desc><br />
</attr><br />
<br />
<attr id="1156" name="zimbraImapMaxConnections" type="integer" cardinality="single" optionalIn="globalConfig,server" flags="serverInherited" requiresRestart="mailbox" since="8.0.0"><br />
<globalConfigValue>200</globalConfigValue><br />
<desc>Maximum number of concurrent IMAP connections allowed. New connections exceeding this limit are rejected.</desc><br />
</attr><br />
<br />
</pre><br />
<br />
==Memory Allocation==<br />
<br />
Both the Java mailboxd and MariaDB/MySQL processes that are part of the mailbox service benefit from more memory, with a few caveats. Allocation of memory to these two processes is done through the local config variable mailboxd_java_heap_size (in ZCS7 and later) mailboxd_java_heap_memory_percent (in ZCS6 and earlier) and the my.cnf variable innodb_buffer_pool_size (details on both are in the following sections). In a new install, ZCS tries to allocate 30% of system memory to the Java heap, and 25% of system memory to innodb buffer pool. Please make sure that you <b>do not configure these values too high</b> for your system. If these values are too high, your system will swap and swapping is extremely detrimental to ZCS performance. Check the JVM Options section to see if you should reduce your heap memory percent. If you believe your system has unused RAM, you can allocate this memory to innodb buffer pool, <b>only after</b> you have monitored your system and made sure your system in not swapping.<br />
<br />
* On a <8GB system, set Java heap size percent to 20 and mysql innodb buffer pool to 20% of system memory.<br />
* On a 8GB system, set Java heap size percent to 30 and mysql innodb buffer pool to 25% of system memory.<br />
* On a 16GB system, set Java heap size percent to 25 and mysql innodb buffer pool to 30% of system memory, monitor and then increase innodb buffer pool size.<br />
* On a 32GB system, set Java heap size percent to 20 and mysql innodb buffer pool to 35% of system memory, monitor and then increase innodb buffer pool size.<br />
<br />
<b>Never run memory hungry processes</b> like rsync or imapsync along side a mailbox server.<br />
<br />
==JVM Options==<br />
<br />
You can tune the Java virtual machine (JVM) that runs the mailbox server application by making changes to a few local config variables. Java runtimes have an automatically garbage collected heap and ZCS maintains caches in the Java heap, and therefore selecting the garbage collector and adjusting the heap size/options are critical to good performance. ZCS by default tries to provide best settings for your system. However, we strongly recommend that all installations double check their JVM settings based on reviewing and understanding this section.<br />
<br />
===Local Config Variables===<br />
<br />
The following local config variables control the options provided to the mailbox server JVM. Changes to these local config variables are preserved across upgrades. For your changes to take effect, you must restart the mailbox service. <br />
<br />
* '''mailboxd_java_options''': Most JVM options, including the type of garbage collector to use, are specified here. Default options included in this local config variable are listed in the next section. Please make sure you have all the ones you should have.<br />
<br />
* '''mailboxd_thread_stack_size''': Should be set to the value 256k. This value is supplied as the parameter to the -Xss JVM option which controls the OS stack size for threads running in the JVM. The default stack size on most systems is unnecessarily high, and given that ZCS mailbox server is highly multi-threaded, a smaller stack size is critical to preventing memory exhaustion because of too many threads. Eg, if there are 3000 threads inside the JVM (see note about IMAP above), you may end up using 750MB just for thread stacks. We have also run tests with 128k stack size in the past, 256k is a conservative recommendation. If you do set a value below 256k, please setup some process to monitor your mailbox.log files for StackOverflowError and adjust the value higher if such errors are found.<br />
<br />
* '''mailboxd_java_heap_memory_percent''': (Deprecated in ZCS 7.0. See mailboxd_java_heap_size below.) This variable determines the percentage of system memory that should be used for Java heap (ie, -Xms and -Xmx JVM option values are derived from this local config variable). The default value is 30% - if you have 8GB of RAM, you will end up with a 2.4GB heap size. It is important to know that the Java process size will be much bigger than the heap size you configure here - the JVM uses memory for other purposes as well, eg, see note about thread stack size above. '''We strongly recommend against increasing''' the heap size to more than 30% of system memory. However, there are many situations in which '''we recommend reducing''' the Java heap size:<br />
** If you have limited amount of memory (ie, < 8GB)<br />
** If you have more than just the mailbox service running on the server (eg, MTA/LDAP)<br />
** If you have a lot of memory. If you have 32GB, 30% is 9.3GB, reduce heap percent to 20. The largest heap we generally recommend is 6.4GB, although some customers with specialized needs have found benefits running a JVM heap size of 10GB or larger. Please be very careful and test first before increasing beyond 6.4GB - beyond a Java heap size of 4-6GB, the system performs better if the memory is assigned to MariaDB/MySQL buffers instead. <br />
** Example configuration:<br />
$ zmlocalconfig -e mailboxd_java_heap_memory_percent=25<br />
<br />
* '''mailboxd_java_heap_size''': New in ZCS 7.0. Number of megabytes to be used as the maximum Java heap size (-Xms and -Xmx) of the JVM running mailboxd. For upgrades from a previous ZCS version, the mailboxd_java_heap_size variable is set according to the mailboxd_java_heap_memory_percent variable. For new installs, the mailboxd_java_help_size variable is set as follows:<br />
** 25% of system memory for upto 16GB of system memory<br />
** 20% of system memory for > 16GB of system memory<br />
** For 32-bit systems with more than 2GB memory, a maximum of 1.5GB is allocated.<br />
** Example configuration - note: this value is set as an integer of MB, so the following is a configuration of 4GB:<br />
$ zmlocalconfig -e mailboxd_java_heap_size=4096<br />
<br />
* '''mailboxd_java_heap_new_size_percent''': New in ZCS 6.0. Percentage of Java heap that should be allocated to the young generation of Java heap. Default is 25%. This local config variable is used to determine the value of the -Xmn option of the JVM.<br />
<br />
* '''zimbra_require_interprocess_security''': The default configuration is zimbra_require_interprocess_security=1, which will force mailboxd to use LDAP STARTTLS for all LDAP queries. This is good for security, but will hurt performance in a large environment on ZCS7 and earlier. STARTTLS requires more resources/processing, but more importantly - JNDI is inefficient with LDAP STARTTLS connections, because it uses individual new connections for each LDAP request rather than connections out of the LDAP connection pool. In ZCS8 and later, Zimbra uses the UnbounID SDK, which allows for connection pooling with StartTLS. As long as your internal network is "trusted", there is generally no reason to use encrypted LDAP requests, since these requests are only on the internal protected network and not accessible to external users. Setting this to 0 is recommended if running ZCS 7 or earlier and it is acceptable from an internal security perspective. More details on this and related options can be found here: [[TLS/STARTTLS_Localconfig_Values|STARTTLS Localconfig Values]]<br />
<br />
<pre><br />
$ zmlocalconfig -e zimbra_require_interprocess_security=0<br />
</pre><br />
<br />
===Recommended Options===<br />
<br />
As of ZCS 8.0, please ensure the following options are configured in the mailboxd_java_options zmlocalconfig setting:<br />
<br />
* '''-server''': Select the JVM runtime code generator suitable for server processes. In the past, this page recommended the client JVM for 32-bit/x86 systems; we now recommend using the server JVM on all platforms. If there is no server code generator for your platform (eg, OS X), the JVM silently ignores the -server option.<br />
<br />
* '''-Djava.awt.headless=true''': Not a performance option, but included here for completeness. Specified so the JVM graphics libraries know they should run in headless mode.<br />
<br />
* '''-XX:+UseConcMarkSweepGC -XX:+UseParNewGC''': Uses the concurrent mark sweep collector (CMS) and the parallel new garbage collector (GC) together. This collector delivers better response time properties used by the largest Zimbra installations, for example a lower pause time during major GC. It is a parallel and mostly-concurrent collector good for the threading ability of large multi-processor systems with larger heap sizes (> 4G). (Note the heap fragmentation and heap requirement are larger.) <br />
<br />
* '''-XX:NewRatio=2''': Sets tenured generation to 2/3 of heap size.<br />
<br />
* '''-XX:PermSize=196m -XX:MaxPermSize=350m''': The default heap size reserved for classes and code is too small for the Zimbra application. These options set them to the required values. Note that ZCS 8.x requires additional PermGen space: PermGen default memory too low - https://bugzilla.zimbra.com/show_bug.cgi?id=78661<br />
<br />
* '''-XX:SoftRefLRUPolicyMSPerMB=1''': This option helps evict entries from the caches held by the mailbox server. Not setting this option will result in softly reachable (ie, evictable) cache objects filling up the heap and causing out of memory errors.<br />
<br />
* '''-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCApplicationStoppedTime''': Turn on logging about garbage collection. On a busy system this generates about 1MB-2MB of log data per day (to zmmailboxd.out). The log file is rotated / deleted automatically and it is worth having these on by default for diagnosis of server performance.<br />
<br />
You should consider enabling the following options which are not on by default:<br />
<br />
* '''-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/some/directory/that/exists/and/is/zimbra/writable''': If you hit out of memory errors, this writes a heap dump that you can provide when you report the issue to us. Note that the Java process will terminate itself on out of memory errors and will be restarted by <tt>zmmailboxdmgr</tt> (5.0) or <tt>zmtomcatmgr</tt> (4.5.x) nanny process.<br />
<br />
* '''-XX:ErrorFile=/some/directory/that/exists/and/is/zimbra/writable'''. This option is useful if you are encountering random JVM process crashes unrelated to out of memory errors - these are very rare, but have been useful in the past (too many threads were created and the JVM crashed).<br />
<br />
Following are the full set of options we would generally recommend for a current version:<br />
<br />
<PRE><br />
$ zmlocalconfig -e mailboxd_java_options="-server -Djava.awt.headless=true \<br />
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:NewRatio=2 \<br />
-XX:PermSize=196m -XX:MaxPermSize=350m -XX:SoftRefLRUPolicyMSPerMB=1 \<br />
-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps \<br />
-XX:+PrintGCApplicationStoppedTime \<br />
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/zimbra/log \<br />
-XX:ErrorFile=/opt/zimbra/log/hs_err_pid%p.log"<br />
</PRE><br />
<br />
===ZCS 4.5.x and Earlier===<br />
<br />
In ZCS 4.5.x and older releases, the local config variables mailboxd_java_options and mailboxd_java_heap_memory_percent were called tomcat_java_options and tomcat_java_heap_memory_percent. There was no local config variable for thread stack size, and thread stack size should be specified in tomcat_java_options.<br />
<br />
===CMS GC and Young Gen Size===<br />
<br />
When enabling concurrent mark sweep GC (-XX:+UseConcMarkSweepGC), it is important to make sure you specify a bigger young generation for ZCS. The default young generation size of 10MB causes too many objects get promoted to the older generation resulting in more frequent older generation collections.<br />
<br />
* If you are using ZCS 6.0 or later, make sure you have mailboxd_java_heap_new_size_percent configured (we recommend 25%) and make sure your mailboxd_java_options doesn't specify a stale -Xmn option.<br />
<br />
* If you are using ZCS 5.0.x or earlier, make sure you have a -Xmn specified in mailboxd_java_options. Eg, if you have 8GB of RAM and 30% for heap (ie 2.4GB for Xmx), add -Xmn600m to mailboxd_java_options (30% of 8GB is 2.4GB, 25% of 2.4GB is 600M).<br />
<br />
===Hints and Examples===<br />
<br />
When modifying mailboxd_java_options, do not change -server from being the first option on the list.<br />
<br />
After changing Java options, when restarting the mailbox service, if the mailbox Java process does not start up, you should check <tt>/var/log/zimbra.log</tt> and <tt>/opt/zimbra/log/zmmailboxd.out</tt> for any errors. If you have a typo or error in the options, the Java process will not start.<br />
<br />
zmlocalconfig does not have an append option. You should exercise care to not blow away existing value of local config variables. Follow a pattern of seeing what's set now and then appending to it.<br />
<br />
The use of the fmt command and multi-line strings (ie, \ terminated lines) in the following examples is just to make this page more readable.<br />
<br />
====Enable HeapDumpOnOutOfMemoryError====<br />
<br />
# Check current value<br />
$ zmlocalconfig mailboxd_java_options | fmt<br />
mailboxd_java_options = -server -Djava.awt.headless=true<br />
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:NewRatio=2<br />
-XX:PermSize=196m -XX:MaxPermSize=350m -XX:SoftRefLRUPolicyMSPerMB=1<br />
-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps<br />
-XX:+PrintGCApplicationStoppedTime<br />
-XX:ErrorFile=/opt/zimbra/log<br />
<br />
# Set new value<br />
zmlocalconfig -e mailboxd_java_options="-server -Djava.awt.headless=true \<br />
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:NewRatio=2 \<br />
-XX:PermSize=196m -XX:MaxPermSize=350m -XX:SoftRefLRUPolicyMSPerMB=1 \<br />
-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps \<br />
-XX:+PrintGCApplicationStoppedTime \<br />
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/zimbra/log \<br />
-XX:ErrorFile=/opt/zimbra/log"<br />
<br />
====Enable CMS GC in ZCS 6.0====<br />
<br />
# This made up example has parallel GC set and a very small <br />
# young generation size<br />
$ zmlocalconfig mailboxd_java_heap_new_size_percent<br />
mailboxd_java_heap_new_size_percent = <b>5</b><br />
$ zmlocalconfig mailboxd_java_options <br />
mailboxd_java_options = -server -Djava.awt.headless=true <br />
<b>-XX:+UseParallelGC</b> -XX:NewRatio=2 -XX:PermSize=128m <br />
-XX:MaxPermSize=128m -XX:SoftRefLRUPolicyMSPerMB=1 <br />
-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps <br />
-XX:+PrintGCApplicationStoppedTime<br />
<br />
# Set young gen size and change parallel to CMS<br />
$ zmlocalconfig -e mailboxd_java_heap_new_size_percent=<b>25</b><br />
$ zmlocalconfig -e \<br />
mailboxd_java_options="-server -Djava.awt.headless=true \<br />
<b>-XX:+UseConcMarkSweepGC</b> -XX:+UseParNewGC -XX:NewRatio=2 -XX:PermSize=128m \<br />
-XX:MaxPermSize=128m -XX:SoftRefLRUPolicyMSPerMB=1 \<br />
-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps \<br />
-XX:+PrintGCApplicationStoppedTime"<br />
<br />
====Enable CMS GC in ZCS 5.0====<br />
<br />
# This server has parallel GC and ZCS 5.0 doesn't have<br />
# a local config to directly control young gen size<br />
$ zmlocalconfig mailboxd_java_options + fmt<br />
mailboxd_java_options = -server -Djava.awt.headless=true<br />
<b>-XX:+UseParallelGC</b> -XX:NewRatio=2 -XX:PermSize=128m<br />
-XX:MaxPermSize=128m -XX:SoftRefLRUPolicyMSPerMB=1<br />
-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps<br />
-XX:+PrintGCApplicationStoppedTime<br />
<br />
# Change parallel to CMS and set young gen size directly<br />
# in mailboxd_java_options (eg assumes heap size is 2GB)<br />
$ zmlocalconfig -e \<br />
mailboxd_java_options="-server -Djava.awt.headless=true \<br />
<b>-XX:+UseConcMarkSweepGC -Xmn500m</b> -XX:NewRatio=2 -XX:PermSize=128m \<br />
-XX:MaxPermSize=128m -XX:SoftRefLRUPolicyMSPerMB=1 \<br />
-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps \<br />
-XX:+PrintGCApplicationStoppedTime"<br />
<br />
===Unrestricted Launcher===<br />
<br />
The Java process that runs the mailbox server application is launched by a manager process. This manager process does two things: make sure certain JVM options are disallowed (for setuid purposes), and to watch and restart the Java process if it died (due a bug, out of memory error, etc). In releases prior to ZCS 5.0.6, the standard launcher program was very strict about JVM options allowed that you could set in mailboxd_java_options, eg, -XX:HeapDumpPath and -XX:ErrorFile were not allowed and required the user of an unrestricted launcher. If you are on these very old releases and you need to add these restricted options, perform the followings before restarting the mailbox service (and revert to the standard launcher once you have diagnosed your problem): <br />
<br />
(as root)<br />
# cd /opt/zimbra/libexec<br />
<br />
For 4.5.x:<br />
# mv zmtomcatmgr zmtomcatmgr.orig<br />
# ln -s zmtomcatmgr.unrestricted zmtomcatmgr<br />
<br />
For 5.0.x:<br />
# mv zmmailboxdmgr zmmailboxdmgr.orig<br />
# ln -s zmmailboxdmgr.unrestricted zmmailboxdmgr<br />
<br />
==MariaDB/MySQL==<br />
<br />
ZCS stores metadata about the content of mailboxes in a MariaDB/MySQL database. MariaDB is used in ZCS 8.5 and later, and MySQL in versions prior to 8.5. ZCS uses the innodb storage engine. Innodb caches data from disk, and performs best when load doesn't cause it to constantly evict pages from its cache and read new ones. Every mailbox store server has its own instance of MariaDB/MySQL so ZCS can scale horizontally. Inside each MariaDB/MySQL server instance, there are 100 mailbox groups each with its own database to avoid creating very large tables that store data for all users. 100 was somewhat arbitrary, but works well.<br />
<br />
MariaDB/MySQL configuration for the mailbox server is stored in <tt>/opt/zimbra/conf/my.cnf</tt> which is not rewritten by a config rewriter, but is preserved across upgrades.<br />
<br />
Configure the following tunables. All settings below should be in the <tt>'''[mysqld]'''</tt> section.<br />
<br />
* Increase the table_cache and innodb_open_files settings to allow MySQL to keep more tables open at one time (can reduce DB I/O substantially). The default settings will be set to similar values when bug 32897 (increase table_cache and innodb_open_files) is implemented:<br />
table_open_cache = 1200<br />
innodb_open_files = 2710<br />
<br />
* Set innodb's cache size. ZCS installer sets this to 40% of RAM in the system. There is a local config variable for mysql memory percent, but today my.cnf doesn't get rewritten after install, so you have to edit my.cnf for this setting if you want to change it. The amount of memory you assign to MySQL and JVM together should not exceed 80% of system memory, and should be lower if you are running other services on the system as well. Here's an example of 40% of a 8GB system:<br />
innodb_buffer_pool_size = 3435973840<br />
<br />
See here for the calculations for other RAM amounts: <br />
[http://wiki.zimbra.com/wiki/Performance_Tuning_Guidelines_for_Large_Deployments#Memory_Allocation Memory Allocation]<br />
<br />
* Innodb writes out pages in its cache after a certain percent of pages are dirty. The default is 90%. This default setting will minimize the total number of writes, but it would cause a major bottleneck in system performance when 90% is reached and database becomes unresponsive because the disk system is writing out all those changes in one shot. We recommend you set the dirty flush ratio to 10%, which does cause a lot more net total IO, but will avoids spiky write load.<br />
innodb_max_dirty_pages_pct = 10<br />
<br />
* MariaDB/MySQL is configured to store its data in files, and the Linux kernel buffers file IO. The buffering provided by the kernel is not useful to innodb at all because innodb is making its own paging decisions - the kernel gets in the way. Bypass the kernel with:<br />
innodb_flush_method = O_DIRECT<br />
<br />
We are often shown http://bugs.mysql.com/bug.php?id=21947 as a reason why O_DIRECT should not be used. There is very little information or evidence in that bug. Our own testing that shown that O_DIRECT makes ZCS database performance better.<br />
<br />
Do '''NOT''' change <tt>innodb_log_file_size</tt>. Change this setting is non-trivial, and requires certain procedures to be followed which are documented in the MySQL manual.<br />
<br />
==Lucene Index==<br />
<br />
ZCS creates and maintains a Lucene search index for every mailbox. As messages arrive, they are added to the Lucene index, and Lucene merges these additions frequently (which results in IO). If multiple additions to a mailbox can be performed together in RAM and flushed at once, write load will be lower. ZCS tries to perform this optimization by keeping open a certain number of mailboxes' index writers (local config <tt>zimbra_index_lru_size</tt>, default 100), and flushes any open index writers periodically (local config <tt>zimbra_index_idle_flush_time</tt>, default 10 minutes). Eg, a single mailbox gets two messages in a 10 minute window between flushes, and its index writer was in cache in that time between the two deliveries, then the index update writes to disk less.<br />
<br />
However, increasing number of index writers is bad under at least these conditions:<br />
<br />
* You do not have sufficient RAM to spare for other purposes (mailbox/message caches, mysql)<br />
* You have a large number of provisioned mailboxes which receive mail<br />
* You frequently send messages to all mailboxes on a single ZCS mailbox node - you blow through index writer cache. Delivering messages to all is one of the peak load times, so you will not have gained any benefit from this optimization in your peak load from this cache.<br />
<br />
We have found that setting index writer cache size to more than 500-1000 on 8GB can result in high GC times and/or out of memory errors, depending on your mailbox usage.<br />
<br />
If you need to disable the index writer cache entirely (because you are seeing out of memory errors, or you have determined that your message delivery rate is so even across many mailboxes that the cache doesn't reduce IO), do this:<br />
<br />
# need to restart mailbox service for this to take effect<br />
$ zmlocalconfig -e zimbra_index_max_uncommitted_operations=0<br />
<br />
The value of 0 for zimbra_index_max_uncommitted_operations overrides any value in zimbra_index_lru_size, ie, 0 uncommitted ops disables the index writer cache use.<br />
<br />
See also bug 24074 (too many recipients should bypass index writer cache).<br />
<br />
In ZCS 5.0.3 "batched indexing" capability (bug 19235) for Lucene indexes was added. In a future release, this will become the default mode (bug 27913: make batched indexing the only indexing mode). To take advantage of this performance enhancement and reduce overall Lucene I/O on a ZCS system you can use a command similar to the following (Note: this is a per COS setting):<br />
<br />
$ for cos in `zmprov gac`; do<br />
zmprov mc $cos zimbraBatchedIndexingSize 20; # see below for size recommendations<br />
done<br />
<br />
The zimbraBatchedIndexingSize value depends on a number of factors including, typical access methods, average size of messages/attachments and CPU/IO capabilities of the server. However, the primary factor currently looked at is the access method for retrieving/viewing email (HTTP vs IMAP vs POP). A zimbraBatchedIndexingSize of 20 should be a good starting point for almost any type of user access patterns, but when the usage for a particular COS is strictly IMAP(S) and/or POP(S) the batch size can go higher (zimbraBatchedIndexingSize == 40, for example). However, please be careful in setting this significantly higher, as operations such as a search can force a batched index run and a larger batch will trigger more messages to be indexed at any point in time.<br />
<br />
==Backup and Recovery==<br />
<br />
The Network Edition of ZCS includes full backup and restore functionality. When ZCS is installed, a backup schedule is automatically added to the cron table. You can change the schedule, but you should not disable it. Backing up the server on a regular basis can help you restore your mail service if an unexpected crash occurs.<br />
<br />
The default full backup is scheduled for 1:00 a.m. every Sunday and the default incremental backups are scheduled for 1:00 a.m. Monday through Saturday. Backups are stored in /opt/zimbra/backup. You will need to make sure that this backup is on a different disk and partition than your data and set up the process to automatically copy the zmbackups offsite or to a different machine or tape backup to minimize the possibility of unrecoverable data loss in the event that the backup disk fails.<br />
<br />
Backup and restore is documented in the Administrator’s Guide and more information can be found elsewhere in the Zimbra wiki.<br />
<br />
TODO: add a note about auto-grouped backups in 5.0.<br />
<br />
==Max message size==<br />
<br />
ZCS 5.0 has much better support for larger messages. In earlier versions large messages caused increased memory pressure and we recommend using the default 10MB max message size. Even with ZCS 5.0 do not increase max message size arbitrarily - large messages do caused increased IO load on the system (by nature), and external mail servers will like not accept large messages.<br />
<br />
==Caches==<br />
<br />
Zimbra has a number of caches that contain account and domain information that can significantly improve performance for larger sites. These caches are stored in the mailboxd JVM heap, and therefore apply only to mailboxd mailstores. Please pay attention to configuring the below values appropriately:<br />
<br />
===Message Cache Size===<br />
<br />
Please see [[Message_Cache]] for the purpose of the message cache along with details on changes in the behavior and configuration of the message cache between ZCS 6 and ZCS 5.<br />
<br />
As of ZCS 6.0, the message cache is an in-memory cache that stores the MIME structures of recently-accessed messages. In ZCS 5.0, the message cache stored not just the message structure, but also the content of messages less than 1MB.<br />
<br />
This cache speeds up retrieval of message content for mail clients such as Mail.app, which repeatedly access the same message in a short time window.<br />
<br />
ZCS 6: on large installs, increase the number entries in the message cache to 10000 (the maximum allowed):<br />
<br />
# NOTE: this is a ZCS 6 specific change!<br />
# can be set on global config or server: 10000 entries in cache<br />
zmprov ms `zmhostname` zimbraMessageCacheSize 10000<br />
<br />
ZCS 5, on large installs, set this cache size to at least 100MB:<br />
<br />
# NOTE: this is a ZCS 5 specific change!<br />
# can be set on global config or server: 104857600 == 100MB<br />
zmprov ms `zmhostname` zimbraMessageCacheSize 104857600<br />
<br />
The message cache hit rate is tracked in '''/opt/zimbra/zmstat/mailboxd.csv''' in the '''mbox_msg_cache''' column. Cache hit rate stats are charted by '''zmstat-chart''' in the "Blob Cache Hit Rate" graph.<br />
<br />
===Domain Caches===<br />
<br />
The mailboxd mailstores contain domain-level caches in the JVM heap.<br />
<br />
In 8.0.7, by default the domain caches will be increased: https://bugzilla.zimbra.com/show_bug.cgi?id=85785#c8<br />
<br />
In earlier versions, you should consider setting these as needed. The general guidance is to set these caches larger than the number of Domains used in your platform, but not so high as to waste memory. These are the values used in ZCS 8.0.7:<br />
<br />
* ldap_cache_domain_maxsize is now 500; increased from 100<br />
* ldap_cache_external_domain_maxsize is now 10000, increased from 2000<br />
<br />
Additional guidance is provided on ldap_cache_domain_maxsize here:<br />
<br />
http://wiki.zimbra.com/wiki/OpenLDAP_Performance_Tuning_8.0#Mailbox_store_tuning_with_LDAP<br />
<br />
* ldap_cache_domain_maxsize. This sets the cache of the number of domains in the server. The default is 100. If more than 100 domains are configured, you should adjust this to the lower of the number of domains you have configured and 30,000. For example, with 45,000 domains, set this to 30000.<br />
<br />
Configuring these values manually is executed as follows on all mailboxd mailstores. Following is an example for a ZCS platform with 20,000-30,000 domains:<br />
<br />
# Apply this to all mailbox servers!<br />
$ zmlocalconfig -e ldap_cache_domain_maxsize=30000<br />
$ zmlocalconfig -e ldap_cache_external_domain_maxsize=10000<br />
$ zmmailboxdctl restart<br />
<br />
==Troubleshooting==<br />
<br />
If HTTP, IMAP or POP3 clients get connection refused errors from the server, and if the server appears to be running OK, initiate a thread dump on the Java mailbox server process. You can do this by using either <tt>~zimbra/libexec/zmtomcatmgr threaddump</tt> command pre-5.0, or <tt>~zimbra/libexec/zmmailboxdmgr threaddump</tt> command in 5.0 or later. The thread dump should show what all the thread pool threads are doing. If they are just idling (usually blocked on a monitor in the thread pool, waiting), this is not a thread pool problem. If all threads are busy doing something else, then either (a) you have hit a bug where the process has wedged itself, or (b) the threads are all busy doing disk IO. Report (a) to us, and for (b) consider better disks or adding RAM for your load or another server.<br />
<br />
=Zimbra OpenLDAP Server=<br />
<br />
Zimbra ZCS LDAP can be configured in traditional master/replica mode, or from ZCS 8.0 or later, as multi-master replication ("MMR"). The LDAP directory server is authoritative for user information, server configuration, etc. Replica LDAP servers can be defined to improve performance and to reduce the load on the master server(s). All updates are made to the master server and these updates are copied to the replica servers.<br />
<br />
* For OpenLDAP Multi-Master Replication with ZCS, please see [[LDAP_Multi_Master_Replication|LDAP Multi-Master Replication]]<br />
* For tuning OpenLDAP with ZCS 8.0 and later, please see [[OpenLDAP_Performance_Tuning_8.0]]<br />
* For tuning OpenLDAP with ZCS 6.0 and ZCS7, please see [[OpenLDAP_Performance_Tuning]]<br />
* For tuning OpenLDAP with ZCS 5.0 and previous, please see [[OpenLDAP_Performance_Tuning_5.0]]<br />
<br />
=Zimbra MTA=<br />
<br />
Please review [http://www.postfix.org/TUNING_README.html the Postfix tuning guide], but double check that your system's values are not already higher before implementing recommendations from that guide. As of this writing, recent Linux kernel defaults are much higher than the values for file-max (16384) and threads-max (2048) recommended in the Postfix tuning guide.<br />
<br />
(Section needs more detail.)<br />
<br />
* Add replicas, make sure postfix is using replicas, postfix bangs on LDAP<br />
* Bayes and auto-white-list perf hit (see bug 18192)<br />
* In /opt/zimbra/conf/spamassassin/local.cf.in, set:<br />
bayes_auto_learn 0 <br />
* In /opt/zimbra/conf/spamassassin/v310.pre (or similar), add a # to comment out this line:<br />
# loadplugin Mail::SpamAssassin::Plugin::AWL <br />
* In /opt/zimbra/conf/spamassassin/local.cf.in, set (regular multi-node ZCS MTAs doesn't NFS safe locking, see SpamAssassin wiki):<br />
lock_method flock <br />
* tmpfs for amavisd-new (see bug 13607)<br />
* Use DNSBLs and whitelist IPs when necessary<br />
* Use mailing list manager (protect your DLs, Zimbra DLs are just an address expansion mechanism)<br />
<br />
=Load Balancers=<br />
<br />
Using load balancers on the Internet gateway point between the Internet and the Zimbra platform is very common. For highest levels of performance and uptime, load balancers are recommended. Many various brands/models of load balancers can be used successfully, so Zimbra will not provide specific requirements. The standard method is to do the following:<br />
<br />
1. Load balance all incoming IMAP/POP/HTTP (and IMAPS/POPS/HTTPS) connections to all available Nginx Proxies.<br />
<br />
2. Use a "persistence" or "stickiness" value in the load balancers of between 5 and 15 minutes. It is highly important to use persistence, in order to optimize incoming requests by continuing to pair a client with a particular nginx proxy for the duration of the session. Not using persistence can create problems with load overhead. Not using persistence can also cause problems when running a mixed-version [[Rolling_Upgrades_for_ZCS|Zimbra Rolling Upgrade]] mode.<br />
<br />
3. Do not use layer-7 (application) level load balancing. Use only layer-4 (TCP) level load balancing. Layer-7 switching can cause significant performance overhead as well as, in some cases, modify packets in such a way that breaks authentication (ZCS uses ZM_AUTH_TOKEN in cookies). The nginx proxies perform their own type of layer-7 switching in order to route traffic, so putting a layer-7 load balancer in front of the nginx proxies can create conflicts.<br />
<br />
4. Do not NAT the source IPs inbound from the Internet. Using inbound source NATting causes the Zimbra platform to lose the real client IP address, which in turn can create all kinds of problems related to open-relaying, loss of DDoS protection, loss of Quality of Service protection, and other problems.<br />
<br />
= See Also =<br />
1. The USE Method - http://www.brendangregg.com/usemethod.html - a methodology for analyzing the performance of any system.<br />
<br />
{{Article_Footer|ZCS 5.0.x|4/11/2007}}<br />
<br />
[[Category:Certified]]<br />
[[Category:LDAP]]<br />
[[Category:Mailbox]]<br />
[[Category:MTA]]<br />
[[Category:MySQL]]<br />
[[Category:Performance and Tuning]]<br />
[[Category:Ports]]<br />
[[Category:ZCS 7.0]]<br />
[[Category:ZCS 6.0]]<br />
[[Category:ZCS 5.0]]</div>Publiskihttps://wiki.zimbra.com/index.php?title=Separation_Of_WebApp_Service_From_Mailstore_In_ZCS8.5&diff=65353Separation Of WebApp Service From Mailstore In ZCS8.52018-05-09T03:09:38Z<p>Publiski: /* Release note items */</p>
<hr />
<div>{{BC|Community Sandbox}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
= Separation Of WebApp Service From Mailstore In ZCS 8.5+ =<br />
{{KB|{{Unsupported}}|{{ZCS 8.6}}|{{ZCS 8.5}}|}}<br />
<br />
The current Zimbra architecture combines the mailstore functionality with all the web functionality on the same server. Aim is to split the combined functionality so that mailstore server can be run independently from web that includes Zimbra Web Client, Zimbra Admin Client and Zimlets. This is how the proxy routes UI and SOAP/REST requests in a split environment.<br />
[[File:Zimbra-split-web-diagram000.png|800px]]<br />
<br />
There are several advantages with the split.<br />
<br />
* Some customers want to run their customized version of Zimbra Web Client and Zimbra Admin Client. Splitting the web apps from mailstore makes the UI customization process to be more “agile”, allowing the customers to roll out customized code without having to restart mailstore servers (zero down time).<br />
* Running webapps requires very few "front end" servers and thus need not touch all webapp or mailstore servers for each update.<br />
* All webapp servers will be completely decoupled from mailbox/Account unlike mailstore which has a affinity to the mailbox account, in other words any webapp server can serve any account request. So rolling out customized UI code doesn't need to shutdown all webapp servers at the same time.<br />
* The split works seamlessly with a cluster based set-up of new version of mailstore server with older versions of ZCS and also supports migrations.<br />
* Splitting the webapps from mailstore considerably decreases the load on mailstore servers which gives additional space to add more mailboxes and handle extra load on mailstore. <br />
<br />
[[File:Zimbra-split-web-diagram001.png|800px]]<br />
<br />
==Installation Process==<br />
==Mail Store Server==<br />
During the backend mailstore installation, the minimum packages we need to select are the zimbra-store, apache, spell, logger and convertd (if installing Network Edition).<br />
<pre>Select the packages to install<br />
Install zimbra-ldap [Y] n<br />
Install zimbra-logger [Y]<br />
Install zimbra-mta [Y] n<br />
Install zimbra-dnscache [N] <br />
Install zimbra-snmp [Y] n<br />
Install zimbra-store [Y] <br />
Install zimbra-apache [Y] <br />
Install zimbra-spell [Y] <br />
Install zimbra-convertd [Y] <br />
Install zimbra-memcached [Y] n<br />
Install zimbra-proxy [Y] n<br />
Install zimbra-archiving [N]</pre><br />
<br />
Note: Remember that if you want to have the convertd working with the last High Fidelity Document Preview, you need to install libreoffice. [https://wiki.zimbra.com/wiki/High_Fidelity_Document_Preview https://wiki.zimbra.com/wiki/High_Fidelity_Document_Preview]<br />
<br />
To use the Mailbox server only as Mail Store Backend, we need to select in the Main Menu the option number 4 (zimbra-store):<br />
Main menu<br />
<br />
1) Common Configuration: <br />
2) zimbra-logger: Enabled <br />
3) zimbra-snmp: Disabled <br />
4) zimbra-store: Enabled <br />
5) zimbra-spell: Enabled <br />
6) zimbra-convertd: Enabled <br />
7) zimbra-proxy: Disabled <br />
8) Default Class of Service Configuration: <br />
9) Enable default backup schedule: yes <br />
s) Save config to file <br />
x) Expand menu <br />
q) Quit <br />
<br />
Select, or 'r' for previous menu [r] 4<br />
<br />
Once inside the Store Menu, we need to disable te option 24, the UI.<br />
<br />
Store configuration<br />
<br />
1) Status: Enabled <br />
2) Create Admin User: yes <br />
3) Admin user to create: admin@zimbra.io <br />
4) Admin Password set <br />
5) Anti-virus quarantine user: virus-quarantine.cpggvaih@zimbra.io<br />
6) Enable automated spam training: yes <br />
7) Spam training user: spam.lwjbfayhot@zimbra.io <br />
8) Non-spam(Ham) training user: ham.vwizoycy@zimbra.io <br />
9) SMTP host: zimbramta01.zimbra.io <br />
10) Web server HTTP port: 8080 <br />
11) Web server HTTPS port: 8443 <br />
12) Web server mode: https <br />
13) IMAP server port: 7143 <br />
14) IMAP server SSL port: 7993 <br />
15) POP server port: 7110 <br />
16) POP server SSL port: 7995 <br />
17) Use spell check server: yes <br />
18) Spell server URL: http://zimbrambox01.zimbra.io:7780/aspell.php<br />
19) Enable version update checks: TRUE <br />
20) Enable version update notifications: TRUE <br />
21) Version update notification email: admin@zimbra.io <br />
22) Version update source email: admin@zimbra.io <br />
23) Install mailstore (service webapp): yes <br />
'''24) Install UI (zimbra,zimbraAdmin webapps): no''' <br />
<br />
Select, or 'r' for previous menu [r] 24<br />
<br />
==UI Server==<br />
On a different server, the one dedicated for just the UI, we will select only the zimbra-store package:<br />
<pre>Select the packages to install<br />
Install zimbra-ldap [Y] n<br />
Install zimbra-logger [Y] n<br />
Install zimbra-mta [Y] n<br />
Install zimbra-dnscache [N] <br />
Install zimbra-snmp [Y] n<br />
Install zimbra-store [Y] <br />
Install zimbra-apache [Y] n<br />
Install zimbra-spell [Y] n<br />
Install zimbra-convertd [Y] n<br />
Install zimbra-memcached [Y] n<br />
Install zimbra-proxy [Y] n<br />
Install zimbra-archiving [N] </pre><br />
<br />
In the Main Menu select the zimbra-store with the option number 4:<br />
Main menu<br />
<br />
1) Common Configuration: <br />
2) zimbra-logger: Disabled <br />
3) zimbra-snmp: Disabled <br />
4) zimbra-store: Enabled <br />
5) zimbra-spell: Disabled <br />
6) zimbra-convertd: Disabled <br />
7) zimbra-proxy: Disabled <br />
8) Default Class of Service Configuration: <br />
9) Enable default backup schedule: yes <br />
s) Save config to file <br />
x) Expand menu <br />
q) Quit <br />
<br />
Select, or 'r' for previous menu [r] 4<br />
<br />
And then click on the option 23 to disable the Mailstore Backend installation:<br />
Store configuration<br />
<br />
1) Status: Enabled <br />
2) Create Admin User: yes <br />
3) Admin user to create: admin@zimbra.io <br />
4) Admin Password set <br />
5) Anti-virus quarantine user: virus-quarantine.cpggvaih@zimbra.io<br />
6) Enable automated spam training: yes <br />
7) Spam training user: spam.lwjbfayhot@zimbra.io <br />
8) Non-spam(Ham) training user: ham.vwizoycy@zimbra.io <br />
9) SMTP host: zimbramta01.zimbra.io <br />
10) Web server HTTP port: 8080 <br />
11) Web server HTTPS port: 8443 <br />
12) Web server mode: https <br />
13) IMAP server port: 7143 <br />
14) IMAP server SSL port: 7993 <br />
15) POP server port: 7110 <br />
16) POP server SSL port: 7995 <br />
17) Use spell check server: yes <br />
18) Spell server URL: http://zimbrambox01.zimbra.io:7780/aspell.php<br />
19) Enable version update checks: TRUE <br />
20) Enable version update notifications: TRUE <br />
21) Version update notification email: admin@zimbra.io <br />
22) Version update source email: admin@zimbra.io <br />
'''23) Install mailstore (service webapp): no''' <br />
24) Install UI (zimbra,zimbraAdmin webapps): yes <br />
<br />
== Release note items == <br />
Next steps are a little few configurations to have all the environment properly working. These are also listed here (https://files.zimbra.com/website/docs/8.5/ZCS_850_NE_ReleaseNotes_UpgradeInst.pdf, page 25)<br />
<br />
* Proxy+Memcached is mandatory - Proxy is the one doing the routing of the UI requests to the webUI server and SOAP/REST requests to the mail server. memcached is mandatory as well for split mode to work. It can be distributed or shared memcached. This is because the webclient server uses memcached to store the mailclient upstream for each client and uses this mailclient server for all subsequent SOAP/REST requests made by that client.<br />
<br />
* Zimbra Web Client must be accessed via Proxy.<br />
<br />
* The localconfig attribute zimbra_zmprov_default_soap_server should be set on the UI server to one of the mailstore servers (running the service webapp).<br />
zimbra@zimbraui01:~$ zmlocalconfig -e zimbra_zmprov_default_soap_server=zimbrambox01.zimbra.io<br />
<br />
* The UI server needs to know where the memcached is running. This is done by setting zimbraMemcachedClientServerList to the server where the memcached is running.<br />
zimbra@zimbraui01:~$ zmprov mcf zimbraMemcachedClientServerList "zimbraproxy01.zimbra.io:11211"<br />
<br />
We can check if we applied properly the command:<br />
zimbra@zimbraui01:~$ zmprov gcf zimbraMemcachedClientServerList<br />
zimbraMemcachedClientServerList:zimbrambox01.zimbra.io:11211<br />
<br />
* Administrator console will work only through the proxy using port 9071 (default value for zimbraAdminProxyPort) instead of 7071 (default value for zimbraAdminPort) after setting zimbraReverseProxyAdminEnabled to TRUE<br />
zimbra@zimbraui01:~$ zmprov ms `zmhostname` zimbraReverseProxyAdminEnabled TRUE<br />
<br />
Another way to do the same as above is by using the following zmproxyconfig command<br />
/opt/zimbra/libexec/zmproxyconfig -e -w -C -H `zmhostname`<br />
<br />
* For service (SOAP/REST) to User Interface (JS/css/html) requests from mailstore server in split mode. Set zimbraWebClientURL on mailstore server to point to the Proxy. <br />
zimbra@zimbraui01:~$ zmprov mcf zimbraWebClientURL https://zimbaui01.zimbra.io<br />
<br />
* Need to have at least one mailstore server and one UI server for the proxy to be up and running and split setup to work.<br />
zmproxyctl restart is required after adding the new UI/mailstore servers to regenerate the correct proxy configurations. <br />
* You must restart mailboxd on mail store and UI nodes, then restart proxy on all nodes where proxy is installed.<br />
zimbra@zimbraui01:~$ zmmailboxdctl restart<br />
zimbra@zimbrambox01:~$ zmmailboxdctl restart<br />
zimbra@zimbraui01:~$ zmproxyctl restart<br />
* In order for some things like change password link, calendar launch in separate window etc to work in split-mode & use proxy instead of mbs the following attributes have to be set:<br />
<br />
zimbraPublicServiceHostname - proxy hostname<br />
zimbraPublicServiceProtocol - proxy protocol (http or https)<br />
zimbraPublicServicePort - proxy port<br />
<br />
Please refer to the following bug for more details [https://bugzilla.zimbra.com/show_bug.cgi?id=91968 https://bugzilla.zimbra.com/show_bug.cgi?id=91968]<br />
<br />
==Proxy routing in a multi-version ZCS environment with split nodes==<br />
<br />
The Proxy now supports cross version lookup for the client UI requests in mixed-version environments consisting of Split/Non-Split nodes. For e.g. UI requests for users on 8.5.0 mailstores will go *only* to one of the webclient servers running 8.5.0 (as zimbraReverseProxyExactServerVersionCheck is ‘on’ by default) or they will go to one of the webclient servers running 8.5.x (i.e the same Major & Minor version if zimbraReverseProxyExactServerVersionCheck is turned ‘off’). <br />
<br />
This is achieved only for the Post-Login UI requests by using an extra ‘version’ field in the ZM_AUTH_TOKEN and then extending the zmauth module in nginx to use this version to figure out an upstream running appropriate version based on the setting of 'exact_version_check' directive in '''/opt/zimbra/conf/nginx/includes/nginx.conf.web'''. In case of rolling upgrade scenarios, you need to make sure that you have atleast one webUI server that will be able to serve the UI requests for each backend mailstore version. Consider tweaking ''zimbraReverseProxyExactServerVersionCheck'' accordingly. <br />
<br />
==Testing the new environment==<br />
We will some tests to check the proper functionality of the Zimbra Collaboration Web Application Server Split.<br />
<br />
* If all 3 servers (UI Server, Mailbox backend and Proxy) are up and running, users can access Zimbra Web Client following the FQDN or IP of the Proxy server.<br />
* When the UI server is off, users cannot access Zimbra Web Client or Zimbra Admin Console. However, the SOAP interface of the Mailbox server is accessible via the Proxy.<br />
* When the Mailbox backend is off, Zimbra Web Client and Zimbra Admin Console will load a login page, but users will not be able to log in.<br />
<br />
==Identified Support/Known Issues==<br />
<br />
<br />
{{Article Footer|Zimbra Collaboration Suite 8.6, 8.5|08/4/2014}}</div>Publiskihttps://wiki.zimbra.com/index.php?title=Postconf_keys&diff=65273Postconf keys2018-04-04T12:38:08Z<p>Publiski: </p>
<hr />
<div>{{BC|Certified}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=Postconf keys=<br />
{{KB|{{ZC}}|{{ZCS 9.0}}|{{ZCS 8.8}}|{{ZCS 8.0}}|}}<br />
= Mapping of postfix configuration keys to LDAP and localconfig by version =<br />
<br />
General mapping of postconf keys to LDAP and/or localconfig keys, by version.<br />
<br />
Some keys are handled via special methods. Those are marked SPECIAL.<br />
<br />
== Mapping Table ==<br />
<br />
{|<br />
! Postconf<br />
! 9.0+<br />
! 8.5+<br />
! 8.0-<br />
|-<br />
|content_filter<br />
|SPECIAL<br />
|SPECIAL<br />
|SPECIAL<br />
|-<br />
|smtpd_end_of_data_restrictions<br />
|SPECIAL<br />
|SPECIAL<br />
|SPECIAL<br />
|-<br />
|policy_time_limit<br />
|zimbraMtaPolicyTimeLimit<br />
|zimbraMtaPolicyTimeLimit<br />
|postfix_policy_time_limit<br />
|-<br />
|mynetworks<br />
|zimbraMtaMyNetworks<br />
|zimbraMtaMyNetworks<br />
|zimbraMtaMyNetworks<br />
|-<br />
|myorigin<br />
|zimbraMtaMyOrigin<br />
|zimbraMtaMyOrigin<br />
|zimbraMtaMyOrigin<br />
|-<br />
|mydestination<br />
|zimbraMtaMyDestination<br />
|zimbraMtaMyDestination<br />
|zimbraMtaMyDestination<br />
|-<br />
|smtpd_milters<br />
|zimbraMtaSmtpdMilters<br />
|zimbraMtaSmtpdMilters<br />
|zimbraMtaSmtpdMilters<br />
|-<br />
|non_smtpd_milters<br />
|zimbraMtaNonSmtpdMilters<br />
|zimbraMtaNonSmtpdMilters<br />
|zimbraMtaNonSmtpdMilters<br />
|-<br />
|myhostname<br />
|zimbra_server_hostname/zimbraMtaMyHostname<br />
|zimbra_server_hostname/zimbraMtaMyHostname<br />
|zimbra_server_hostname/zimbraMtaMyHostname<br />
|-<br />
|recipient_delimiter<br />
|zimbraMtaRecipientDelimiter<br />
|zimbraMtaRecipientDelimiter<br />
|zimbraMtaRecipientDelimiter<br />
|-<br />
|smtpd_sasl_auth_enable<br />
|zimbraMtaSaslAuthEnable<br />
|zimbraMtaSaslAuthEnable<br />
|zimbraMtaSaslAuthEnable<br />
|-<br />
|disable_dns_lookups<br />
|zimbraMtaDnsLookupsEnabled<br />
|zimbraMtaDnsLookupsEnabled<br />
|zimbraMtaDnsLookupsEnabled<br />
|-<br />
|message_size_limit<br />
|zimbraMtaMaxMessageSize<br />
|zimbraMtaMaxMessageSize<br />
|zimbraMtaMaxMessageSize<br />
|-<br />
|max_use<br />
|zimbraMtaMaxUse<br />
|zimbraMtaMaxUse<br />
|N/A<br />
|-<br />
|relayhost<br />
|zimbraMtaRelayHost<br />
|zimbraMtaRelayHost<br />
|zimbraMtaRelayHost<br />
|-<br />
|smtp_fallback_relay<br />
|zimbraMtaFallbackRelayHost<br />
|zimbraMtaFallbackRelayHost<br />
|zimbraMtaFallbackRelayHost<br />
|-<br />
|smtp_generic_maps<br />
|zimbraMtaSmtpGenericMaps<br />
|zimbraMtaSmtpGenericMaps<br />
|zimbraMtaFallbackRelayHost<br />
|-<br />
|smtpd_recipient_restrictions<br />
|SPECIAL<br />
|SPECIAL<br />
|SPECIAL<br />
|-<br />
|smtpd_relay_restrictions<br />
|SPECIAL<br />
|SPECIAL<br />
|SPECIAL<br />
|-<br />
|smtpd_sender_restrictions<br />
|SPECIAL<br />
|SPECIAL<br />
|SPECIAL<br />
|-<br />
|smtpd_sender_login_maps<br />
|zimbraMtaSmtpdSenderLoginMaps<br />
|SPECIAL<br />
|N/A<br />
|-<br />
|alias_maps<br />
|zimbraMtaAliasMaps<br />
|zimbraMtaAliasMaps<br />
|postfix_alias_maps<br />
|-<br />
|broken_sasl_auth_clients<br />
|zimbraMtaBrokenSaslAuthClients<br />
|zimbraMtaBrokenSaslAuthClients<br />
|postfix_broken_sasl_auth_clients<br />
|-<br />
|bounce_queue_lifetime<br />
|zimbraMtaBounceQueueLifetime<br />
|zimbraMtaBounceQueueLifetime<br />
|postfix_bounce_queue_lifetime<br />
|-<br />
|bounce_notice_recipient<br />
|zimbraMtaBounceNoticeRecipient<br />
|zimbraMtaBounceNoticeRecipient<br />
|postfix_bounce_notice_recipient<br />
|-<br />
|mail_owner<br />
|postfix_mail_owner<br />
|postfix_mail_owner<br />
|postfix_mail_owner<br />
|-<br />
|setgid_group<br />
|postfix_setgid_group<br />
|postfix_setgid_group<br />
|postfix_setgid_group<br />
|-<br />
|command_directory<br />
|zimbraMtaCommandDirectory<br />
|zimbraMtaCommandDirectory<br />
|postfix_command_directory<br />
|-<br />
|daemon_directory<br />
|zimbraMtaDaemonDirectory<br />
|zimbraMtaDaemonDirectory<br />
|postfix_daemon_directory<br />
|-<br />
|delay_warning_time<br />
|zimbraMtaDelayWarningTime<br />
|zimbraMtaDelayWarningTime<br />
|postfix_delay_warning_time<br />
|-<br />
|default_process_limit<br />
|zimbraMtaDefaultProcessLimit<br />
|zimbraMtaDefaultProcessLimit<br />
|N/A<br />
|-<br />
|lmdb_map_size<br />
|zimbraMtaLmdbMapSize<br />
|zimbraMtaLmdbMapSize<br />
|N/A<br />
|-<br />
|header_checks<br />
|zimbraMtaHeaderChecks<br />
|zimbraMtaHeaderChecks<br />
|postfix_header_checks<br />
|-<br />
|mailq_path<br />
|zimbraMtaMailqPath<br />
|zimbraMtaMailqPath<br />
|postfix_mailq_path<br />
|-<br />
|manpage_directory<br />
|zimbraMtaManpageDirectory<br />
|zimbraMtaManpageDirectory<br />
|postfix_manpage_directory<br />
|-<br />
|newaliases_path<br />
|zimbraMtaNewaliasesPath<br />
|zimbraMtaNewaliasesPath<br />
|postfix_newaliases_path<br />
|-<br />
|notify_classes<br />
|zimbraMtaNotifyClasses<br />
|zimbraMtaNotifyClasses<br />
|postfix_notify_classes<br />
|-<br />
|queue_directory<br />
|zimbraMtaQueueDirectory<br />
|zimbraMtaQueueDirectory<br />
|postfix_queue_directory<br />
|-<br />
|smtpd_sasl_authenticated_header<br />
|zimbraMtaSmtpdSaslAuthenticatedHeader<br />
|zimbraMtaSmtpdSaslAuthenticatedHeader<br />
|postfix_smtpd_sasl_authenticated_header<br />
|-<br />
|sender_canonical_maps<br />
|zimbraMtaSenderCanonicalMaps<br />
|zimbraMtaSenderCanonicalMaps<br />
|postfix_sender_canonical_maps<br />
|-<br />
|sendmail_path<br />
|zimbraMtaSendmailPath<br />
|zimbraMtaSendmailPath<br />
|postfix_sendmail_path<br />
|-<br />
|smtpd_banner<br />
|zimbraMtaSmtpdBanner<br />
|zimbraMtaSmtpdBanner<br />
|postfix_smtpd_banner<br />
|-<br />
|smtpd_client_restrictions<br />
|zimbraMtaSmtpdClientRestrictions<br />
|zimbraMtaSmtpdClientRestrictions<br />
|postfix_smtpd_client_restrictions<br />
|-<br />
|smtpd_client_port_logging<br />
|zimbraMtaSmtpdClientPortLogging<br />
|zimbraMtaSmtpdClientPortLogging<br />
|zimbraMtaSmtpdClientPortLogging<br />
|-<br />
|smtpd_data_restrictions<br />
|zimbraMtaSmtpdDataRestrictions<br />
|zimbraMtaSmtpdDataRestrictions<br />
|postfix_smtpd_data_restrictions<br />
|-<br />
|smtpd_helo_required<br />
|zimbraMtaSmtpdHeloRequired<br />
|zimbraMtaSmtpdHeloRequired<br />
|postfix_smtpd_helo_required<br />
|-<br />
|smtpd_proxy_timeout<br />
|zimbraMtaSmtpdProxyTimeout<br />
|zimbraMtaSmtpdProxyTimeout<br />
|postfix_smtpd_proxy_timeout<br />
|-<br />
|smtpd_reject_unlisted_recipient<br />
|zimbraMtaSmtpdRejectUnlistedRecipient<br />
|zimbraMtaSmtpdRejectUnlistedRecipient<br />
|postfix_smtpd_reject_unlisted_recipient<br />
|-<br />
|smtpd_reject_unlisted_sender<br />
|zimbraMtaSmtpdRejectUnlistedSender<br />
|zimbraMtaSmtpdRejectUnlistedSender<br />
|postfix_smtpd_reject_unlisted_sender<br />
|-<br />
|smtpd_tls_ask_ccert<br />
|zimbraMtaSmtpdTlsAskCcert<br />
|zimbraMtaSmtpdTlsAskCcert<br />
|N/A<br />
|-<br />
|smtpd_tls_auth_only<br />
|zimbraMtaTlsAuthOnly<br />
|zimbraMtaTlsAuthOnly<br />
|zimbraMtaTlsAuthOnly<br />
|-<br />
|smtpd_tls_CAfile<br />
|zimbraMtaSmtpdTlsCAfile<br />
|zimbraMtaSmtpdTlsCAfile<br />
|N/A<br />
|-<br />
|smtpd_tls_CApath<br />
|zimbraMtaSmtpdTlsCApath<br />
|zimbraMtaSmtpdTlsCApath<br />
|N/A<br />
|-<br />
|smtpd_tls_ccert_verifydepth<br />
|zimbraMtaSmtpdTlsCcertVerifydepth<br />
|zimbraMtaSmtpdTlsCcertVerifydepth<br />
|N/A<br />
|-<br />
|smtpd_tls_ciphers<br />
|zimbraMtaSmtpdTlsCiphers<br />
|zimbraMtaSmtpdTlsCiphers<br />
|N/A<br />
|-<br />
|smtpd_tls_exclude_ciphers<br />
|zimbraMtaSmtpdTlsExcludeCiphers<br />
|zimbraMtaSmtpdTlsExcludeCiphers<br />
|N/A<br />
|-<br />
|smtpd_tls_loglevel<br />
|zimbraMtaSmtpdTlsLoglevel<br />
|zimbraMtaSmtpdTlsLoglevel<br />
|postfix_smtpd_tls_loglevel<br />
|-<br />
|smtpd_tls_mandatory_ciphers<br />
|zimbraMtaSmtpdTlsMandatoryCiphers<br />
|zimbraMtaSmtpdTlsMandatoryCiphers<br />
|N/A<br />
|-<br />
|smtpd_tls_protocols<br />
|zimbraMtaSmtpdTlsProtocols<br />
|zimbraMtaSmtpdTlsProtocols<br />
|N/A<br />
|-<br />
|smtpd_tls_security_level<br />
|zimbraMtaTlsSecurityLevel<br />
|zimbraMtaTlsSecurityLevel<br />
|zimbraMtaTlsSecurityLevel<br />
|-<br />
|smtpd_error_sleep_time<br />
|zimbraMtaSmtpdErrorSleepTime<br />
|zimbraMtaSmtpdErrorSleepTime<br />
|postfix_smtpd_error_sleep_time<br />
|-<br />
|smtpd_hard_error_limit<br />
|zimbraMtaSmtpdHardErrorLimit<br />
|zimbraMtaSmtpdHardErrorLimit<br />
|postfix_smtpd_hard_error_limit<br />
|-<br />
|smtpd_soft_error_limit<br />
|zimbraMtaStpdSoftErrorLimit<br />
|zimbraMtaStpdSoftErrorLimit<br />
|postfix_smtpd_soft_error_limit<br />
|-<br />
|in_flow_delay<br />
|zimbraMtaInFlowDelay<br />
|zimbraMtaInFlowDelay<br />
|postfix_in_flow_delay<br />
|-<br />
|import_environment<br />
|zimbraMtaImportEnvironment<br />
|zimbraMtaImportEnvironment<br />
|postfix_import_environment<br />
|-<br />
|queue_run_delay<br />
|zimbraMtaQueueRunDelay<br />
|zimbraMtaQueueRunDelay<br />
|postfix_queue_run_delay<br />
|-<br />
|minimal_backoff_time<br />
|zimbraMtaMinimalBackoffTime<br />
|zimbraMtaMinimalBackoffTime<br />
|postfix_minimal_backoff_time<br />
|-<br />
|maximal_backoff_time<br />
|zimbraMtaMaximalBackoffTime<br />
|zimbraMtaMaximalBackoffTime<br />
|postfix_maximal_backoff_time<br />
|-<br />
|lmtp_connection_cache_destinations<br />
|zimbraMtaLmtpConnectionCacheDestinations<br />
|zimbraMtaLmtpConnectionCacheDestinations<br />
|postfix_lmtp_connection_cache_destinations<br />
|-<br />
|lmtp_connection_cache_time_limit<br />
|zimbraMtaLmtpConnectionCacheTimeLimit<br />
|zimbraMtaLmtpConnectionCacheTimeLimit<br />
|postfix_lmtp_connection_cache_time_limit<br />
|-<br />
|lmtp_host_lookup<br />
|zimbraMtaLmtpHostLookup<br />
|zimbraMtaLmtpHostLookup<br />
|postfix_lmtp_host_lookup<br />
|-<br />
|transport_maps<br />
|zimbraMtaTransportMaps<br />
|zimbraMtaTransportMaps<br />
|postfix_transport_maps<br />
|-<br />
|propagate_unmatched_extensions<br />
|zimbraMtaPropagateUnmatchedExtensions<br />
|zimbraMtaPropagateUnmatchedExtensions<br />
|postfix_propagate_unmatched_extensions<br />
|-<br />
|virtual_alias_domains<br />
|zimbraMtaVirtualAliasDomains<br />
|zimbraMtaVirtualAliasDomains<br />
|postfix_virtual_alias_domains<br />
|-<br />
|virtual_alias_expansion_limit<br />
|zimbraMtaVirtualAliasExpansionLimit<br />
|zimbraMtaVirtualAliasExpansionLimit<br />
|postfix_virtual_alias_expansion_limit<br />
|-<br />
|virtual_alias_maps<br />
|zimbraMtaVirtualAliasMaps<br />
|zimbraMtaVirtualAliasMaps<br />
|postfix_virtual_alias_maps<br />
|-<br />
|virtual_mailbox_domains<br />
|zimbraMtaVirtualMailboxDomains<br />
|zimbraMtaVirtualMailboxDomains<br />
|postfix_virtual_mailbox_domains<br />
|-<br />
|virtual_mailbox_maps<br />
|zimbraMtaVirtualMailboxMaps<br />
|zimbraMtaVirtualMailboxMaps<br />
|postfix_virtual_mailbox_maps<br />
|-<br />
|virtual_transport<br />
|zimbraMtaSmtpdVirtualTransport<br />
|zimbraMtaSmtpdVirtualTransport<br />
|postfix_virtual_transport<br />
|-<br />
|always_add_missing_headers<br />
|zimbraMtaAlwaysAddMissingHeaders<br />
|zimbraMtaAlwaysAddMissingHeaders<br />
|postfix_always_add_missing_headers<br />
|-<br />
|smtpd_sasl_security_options<br />
|zimbraMtaSmtpdSaslSecurityOptions<br />
|zimbraMtaSmtpdSaslSecurityOptions<br />
|postfix_smtpd_sasl_security_options<br />
|-<br />
|smtpd_sasl_tls_security_options<br />
|zimbraMtaSmtpdSaslTlsSecurityOptions<br />
|zimbraMtaSmtpdSaslTlsSecurityOptions<br />
|postfix_smtpd_sasl_tls_security_options<br />
|-<br />
|smtp_helo_name<br />
|zimbraMtaSmtpHeloName<br />
|zimbraMtaSmtpHeloName<br />
|postfix_smtp_helo_name<br />
|-<br />
|smtp_cname_overrides_servername<br />
|zimbraMtaSmtpCnameOverridesServername<br />
|zimbraMtaSmtpCnameOverridesServername<br />
|postfix_smtp_cname_overrides_servername<br />
|-<br />
|smtp_sasl_auth_enable<br />
|zimbraMtaSmtpSaslAuthEnable<br />
|zimbraMtaSmtpSaslAuthEnable<br />
|postfix_smtp_sasl_auth_enable<br />
|-<br />
|smtp_sasl_security_options<br />
|zimbraMtaSmtpSaslSecurityOptions<br />
|zimbraMtaSmtpSaslSecurityOptions<br />
|postfix_smtp_sasl_security_options<br />
|-<br />
|smtp_tls_CAfile<br />
|zimbraMtaSmtpTlsCAfile<br />
|zimbraMtaSmtpTlsCAfile<br />
|N/A<br />
|-<br />
|smtp_tls_CApath<br />
|zimbraMtaSmtpTlsCApath<br />
|zimbraMtaSmtpTlsCApath<br />
|N/A<br />
|-<br />
|tls_append_default_CA<br />
|zimbraMtaTlsAppendDefaultCA<br />
|zimbraMtaTlsAppendDefaultCA<br />
|N/A<br />
|-<br />
|smtp_tls_security_level<br />
|zimbraMtaSmtpTlsSecurityLevel<br />
|zimbraMtaSmtpTlsSecurityLevel<br />
|postfix_smtp_tls_security_level<br />
|-<br />
|smtp_tls_loglevel<br />
|zimbraMtaSmtpTlsLoglevel<br />
|zimbraMtaSmtpTlsLoglevel<br />
|N/A<br />
|-<br />
|smtp_tls_ciphers<br />
|zimbraMtaSmtpTlsCiphers<br />
|zimbraMtaSmtpTlsCiphers<br />
|N/A<br />
|-<br />
|smtp_tls_mandatory_ciphers<br />
|zimbraMtaSmtpTlsMandatoryCiphers<br />
|zimbraMtaSmtpTlsMandatoryCiphers<br />
|N/A<br />
|-<br />
|smtp_sasl_mechanism_filter<br />
|zimbraMtaSmtpSaslMechanismFilter<br />
|zimbraMtaSmtpSaslMechanismFilter<br />
|postfix_smtp_sasl_mechanism_filter<br />
|-<br />
|smtp_sasl_password_maps<br />
|zimbraMtaSmtpSaslPasswordMaps<br />
|zimbraMtaSmtpSaslPasswordMaps<br />
|postfix_smtp_sasl_password_maps<br />
|-<br />
|milter_connect_timeout<br />
|zimbraMtaMilterConnectTimeout<br />
|zimbraMtaMilterConnectTimeout<br />
|postfix_milter_connect_timeout<br />
|-<br />
|milter_command_timeout<br />
|zimbraMtaMilterCommandTimeout<br />
|zimbraMtaMilterCommandTimeout<br />
|postfix_milter_command_timeout<br />
|-<br />
|milter_content_timeout<br />
|zimbraMtaMilterContentTimeout<br />
|zimbraMtaMilterContentTimeout<br />
|postfix_milter_content_timeout<br />
|-<br />
|milter_default_action<br />
|zimbraMtaMilterDefaultAction<br />
|zimbraMtaMilterDefaultAction<br />
|postfix_milter_default_action<br />
|-<br />
|inet_protocols<br />
|zimbraPostconfProtocol<br />
|zimbraPostconfProtocol<br />
|zimbraPostconfProtocol<br />
|-<br />
|unverified_recipient_defer_code<br />
|zimbraMtaUnverifiedRecipientDeferCode<br />
|zimbraMtaUnverifiedRecipientDeferCode<br />
|N/A<br />
|-<br />
|address_verify_poll_count<br />
|zimbraMtaAddressVerifyPollCount<br />
|zimbraMtaAddressVerifyPollCount<br />
|N/A<br />
|-<br />
|address_verify_poll_delay<br />
|zimbraMtaAddressVerifyPollDelay<br />
|zimbraMtaAddressVerifyPollDelay<br />
|N/A<br />
|-<br />
|address_verify_negative_refresh_time<br />
|zimbraMtaAddressVerifyNegativeRefreshTime<br />
|zimbraMtaAddressVerifyNegativeRefreshTime<br />
|N/A<br />
|-<br />
|address_verify_positive_refresh_time<br />
|zimbraMtaAddressVerifyPositiveRefreshTime<br />
|zimbraMtaAddressVerifyPositiveRefreshTime<br />
|N/A<br />
|}<br />
{{Article Footer|Zimbra Collaboration Suite 9.0, 8.6, 8.5|08/4/2014}}</div>Publiskihttps://wiki.zimbra.com/index.php?title=Postconf_keys&diff=65272Postconf keys2018-04-04T12:37:37Z<p>Publiski: </p>
<hr />
<div>{{BC|Certified}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=Postconf keys=<br />
{{KB|{{ZC}}|{{ZCS 9.0}}|{{ZCS 8.6}}|{{ZCS 8.0}}|}}<br />
= Mapping of postfix configuration keys to LDAP and localconfig by version =<br />
<br />
General mapping of postconf keys to LDAP and/or localconfig keys, by version.<br />
<br />
Some keys are handled via special methods. Those are marked SPECIAL.<br />
<br />
== Mapping Table ==<br />
<br />
{|<br />
! Postconf<br />
! 9.0+<br />
! 8.5+<br />
! 8.0-<br />
|-<br />
|content_filter<br />
|SPECIAL<br />
|SPECIAL<br />
|SPECIAL<br />
|-<br />
|smtpd_end_of_data_restrictions<br />
|SPECIAL<br />
|SPECIAL<br />
|SPECIAL<br />
|-<br />
|policy_time_limit<br />
|zimbraMtaPolicyTimeLimit<br />
|zimbraMtaPolicyTimeLimit<br />
|postfix_policy_time_limit<br />
|-<br />
|mynetworks<br />
|zimbraMtaMyNetworks<br />
|zimbraMtaMyNetworks<br />
|zimbraMtaMyNetworks<br />
|-<br />
|myorigin<br />
|zimbraMtaMyOrigin<br />
|zimbraMtaMyOrigin<br />
|zimbraMtaMyOrigin<br />
|-<br />
|mydestination<br />
|zimbraMtaMyDestination<br />
|zimbraMtaMyDestination<br />
|zimbraMtaMyDestination<br />
|-<br />
|smtpd_milters<br />
|zimbraMtaSmtpdMilters<br />
|zimbraMtaSmtpdMilters<br />
|zimbraMtaSmtpdMilters<br />
|-<br />
|non_smtpd_milters<br />
|zimbraMtaNonSmtpdMilters<br />
|zimbraMtaNonSmtpdMilters<br />
|zimbraMtaNonSmtpdMilters<br />
|-<br />
|myhostname<br />
|zimbra_server_hostname/zimbraMtaMyHostname<br />
|zimbra_server_hostname/zimbraMtaMyHostname<br />
|zimbra_server_hostname/zimbraMtaMyHostname<br />
|-<br />
|recipient_delimiter<br />
|zimbraMtaRecipientDelimiter<br />
|zimbraMtaRecipientDelimiter<br />
|zimbraMtaRecipientDelimiter<br />
|-<br />
|smtpd_sasl_auth_enable<br />
|zimbraMtaSaslAuthEnable<br />
|zimbraMtaSaslAuthEnable<br />
|zimbraMtaSaslAuthEnable<br />
|-<br />
|disable_dns_lookups<br />
|zimbraMtaDnsLookupsEnabled<br />
|zimbraMtaDnsLookupsEnabled<br />
|zimbraMtaDnsLookupsEnabled<br />
|-<br />
|message_size_limit<br />
|zimbraMtaMaxMessageSize<br />
|zimbraMtaMaxMessageSize<br />
|zimbraMtaMaxMessageSize<br />
|-<br />
|max_use<br />
|zimbraMtaMaxUse<br />
|zimbraMtaMaxUse<br />
|N/A<br />
|-<br />
|relayhost<br />
|zimbraMtaRelayHost<br />
|zimbraMtaRelayHost<br />
|zimbraMtaRelayHost<br />
|-<br />
|smtp_fallback_relay<br />
|zimbraMtaFallbackRelayHost<br />
|zimbraMtaFallbackRelayHost<br />
|zimbraMtaFallbackRelayHost<br />
|-<br />
|smtp_generic_maps<br />
|zimbraMtaSmtpGenericMaps<br />
|zimbraMtaSmtpGenericMaps<br />
|zimbraMtaFallbackRelayHost<br />
|-<br />
|smtpd_recipient_restrictions<br />
|SPECIAL<br />
|SPECIAL<br />
|SPECIAL<br />
|-<br />
|smtpd_relay_restrictions<br />
|SPECIAL<br />
|SPECIAL<br />
|SPECIAL<br />
|-<br />
|smtpd_sender_restrictions<br />
|SPECIAL<br />
|SPECIAL<br />
|SPECIAL<br />
|-<br />
|smtpd_sender_login_maps<br />
|zimbraMtaSmtpdSenderLoginMaps<br />
|SPECIAL<br />
|N/A<br />
|-<br />
|alias_maps<br />
|zimbraMtaAliasMaps<br />
|zimbraMtaAliasMaps<br />
|postfix_alias_maps<br />
|-<br />
|broken_sasl_auth_clients<br />
|zimbraMtaBrokenSaslAuthClients<br />
|zimbraMtaBrokenSaslAuthClients<br />
|postfix_broken_sasl_auth_clients<br />
|-<br />
|bounce_queue_lifetime<br />
|zimbraMtaBounceQueueLifetime<br />
|zimbraMtaBounceQueueLifetime<br />
|postfix_bounce_queue_lifetime<br />
|-<br />
|bounce_notice_recipient<br />
|zimbraMtaBounceNoticeRecipient<br />
|zimbraMtaBounceNoticeRecipient<br />
|postfix_bounce_notice_recipient<br />
|-<br />
|mail_owner<br />
|postfix_mail_owner<br />
|postfix_mail_owner<br />
|postfix_mail_owner<br />
|-<br />
|setgid_group<br />
|postfix_setgid_group<br />
|postfix_setgid_group<br />
|postfix_setgid_group<br />
|-<br />
|command_directory<br />
|zimbraMtaCommandDirectory<br />
|zimbraMtaCommandDirectory<br />
|postfix_command_directory<br />
|-<br />
|daemon_directory<br />
|zimbraMtaDaemonDirectory<br />
|zimbraMtaDaemonDirectory<br />
|postfix_daemon_directory<br />
|-<br />
|delay_warning_time<br />
|zimbraMtaDelayWarningTime<br />
|zimbraMtaDelayWarningTime<br />
|postfix_delay_warning_time<br />
|-<br />
|default_process_limit<br />
|zimbraMtaDefaultProcessLimit<br />
|zimbraMtaDefaultProcessLimit<br />
|N/A<br />
|-<br />
|lmdb_map_size<br />
|zimbraMtaLmdbMapSize<br />
|zimbraMtaLmdbMapSize<br />
|N/A<br />
|-<br />
|header_checks<br />
|zimbraMtaHeaderChecks<br />
|zimbraMtaHeaderChecks<br />
|postfix_header_checks<br />
|-<br />
|mailq_path<br />
|zimbraMtaMailqPath<br />
|zimbraMtaMailqPath<br />
|postfix_mailq_path<br />
|-<br />
|manpage_directory<br />
|zimbraMtaManpageDirectory<br />
|zimbraMtaManpageDirectory<br />
|postfix_manpage_directory<br />
|-<br />
|newaliases_path<br />
|zimbraMtaNewaliasesPath<br />
|zimbraMtaNewaliasesPath<br />
|postfix_newaliases_path<br />
|-<br />
|notify_classes<br />
|zimbraMtaNotifyClasses<br />
|zimbraMtaNotifyClasses<br />
|postfix_notify_classes<br />
|-<br />
|queue_directory<br />
|zimbraMtaQueueDirectory<br />
|zimbraMtaQueueDirectory<br />
|postfix_queue_directory<br />
|-<br />
|smtpd_sasl_authenticated_header<br />
|zimbraMtaSmtpdSaslAuthenticatedHeader<br />
|zimbraMtaSmtpdSaslAuthenticatedHeader<br />
|postfix_smtpd_sasl_authenticated_header<br />
|-<br />
|sender_canonical_maps<br />
|zimbraMtaSenderCanonicalMaps<br />
|zimbraMtaSenderCanonicalMaps<br />
|postfix_sender_canonical_maps<br />
|-<br />
|sendmail_path<br />
|zimbraMtaSendmailPath<br />
|zimbraMtaSendmailPath<br />
|postfix_sendmail_path<br />
|-<br />
|smtpd_banner<br />
|zimbraMtaSmtpdBanner<br />
|zimbraMtaSmtpdBanner<br />
|postfix_smtpd_banner<br />
|-<br />
|smtpd_client_restrictions<br />
|zimbraMtaSmtpdClientRestrictions<br />
|zimbraMtaSmtpdClientRestrictions<br />
|postfix_smtpd_client_restrictions<br />
|-<br />
|smtpd_client_port_logging<br />
|zimbraMtaSmtpdClientPortLogging<br />
|zimbraMtaSmtpdClientPortLogging<br />
|zimbraMtaSmtpdClientPortLogging<br />
|-<br />
|smtpd_data_restrictions<br />
|zimbraMtaSmtpdDataRestrictions<br />
|zimbraMtaSmtpdDataRestrictions<br />
|postfix_smtpd_data_restrictions<br />
|-<br />
|smtpd_helo_required<br />
|zimbraMtaSmtpdHeloRequired<br />
|zimbraMtaSmtpdHeloRequired<br />
|postfix_smtpd_helo_required<br />
|-<br />
|smtpd_proxy_timeout<br />
|zimbraMtaSmtpdProxyTimeout<br />
|zimbraMtaSmtpdProxyTimeout<br />
|postfix_smtpd_proxy_timeout<br />
|-<br />
|smtpd_reject_unlisted_recipient<br />
|zimbraMtaSmtpdRejectUnlistedRecipient<br />
|zimbraMtaSmtpdRejectUnlistedRecipient<br />
|postfix_smtpd_reject_unlisted_recipient<br />
|-<br />
|smtpd_reject_unlisted_sender<br />
|zimbraMtaSmtpdRejectUnlistedSender<br />
|zimbraMtaSmtpdRejectUnlistedSender<br />
|postfix_smtpd_reject_unlisted_sender<br />
|-<br />
|smtpd_tls_ask_ccert<br />
|zimbraMtaSmtpdTlsAskCcert<br />
|zimbraMtaSmtpdTlsAskCcert<br />
|N/A<br />
|-<br />
|smtpd_tls_auth_only<br />
|zimbraMtaTlsAuthOnly<br />
|zimbraMtaTlsAuthOnly<br />
|zimbraMtaTlsAuthOnly<br />
|-<br />
|smtpd_tls_CAfile<br />
|zimbraMtaSmtpdTlsCAfile<br />
|zimbraMtaSmtpdTlsCAfile<br />
|N/A<br />
|-<br />
|smtpd_tls_CApath<br />
|zimbraMtaSmtpdTlsCApath<br />
|zimbraMtaSmtpdTlsCApath<br />
|N/A<br />
|-<br />
|smtpd_tls_ccert_verifydepth<br />
|zimbraMtaSmtpdTlsCcertVerifydepth<br />
|zimbraMtaSmtpdTlsCcertVerifydepth<br />
|N/A<br />
|-<br />
|smtpd_tls_ciphers<br />
|zimbraMtaSmtpdTlsCiphers<br />
|zimbraMtaSmtpdTlsCiphers<br />
|N/A<br />
|-<br />
|smtpd_tls_exclude_ciphers<br />
|zimbraMtaSmtpdTlsExcludeCiphers<br />
|zimbraMtaSmtpdTlsExcludeCiphers<br />
|N/A<br />
|-<br />
|smtpd_tls_loglevel<br />
|zimbraMtaSmtpdTlsLoglevel<br />
|zimbraMtaSmtpdTlsLoglevel<br />
|postfix_smtpd_tls_loglevel<br />
|-<br />
|smtpd_tls_mandatory_ciphers<br />
|zimbraMtaSmtpdTlsMandatoryCiphers<br />
|zimbraMtaSmtpdTlsMandatoryCiphers<br />
|N/A<br />
|-<br />
|smtpd_tls_protocols<br />
|zimbraMtaSmtpdTlsProtocols<br />
|zimbraMtaSmtpdTlsProtocols<br />
|N/A<br />
|-<br />
|smtpd_tls_security_level<br />
|zimbraMtaTlsSecurityLevel<br />
|zimbraMtaTlsSecurityLevel<br />
|zimbraMtaTlsSecurityLevel<br />
|-<br />
|smtpd_error_sleep_time<br />
|zimbraMtaSmtpdErrorSleepTime<br />
|zimbraMtaSmtpdErrorSleepTime<br />
|postfix_smtpd_error_sleep_time<br />
|-<br />
|smtpd_hard_error_limit<br />
|zimbraMtaSmtpdHardErrorLimit<br />
|zimbraMtaSmtpdHardErrorLimit<br />
|postfix_smtpd_hard_error_limit<br />
|-<br />
|smtpd_soft_error_limit<br />
|zimbraMtaStpdSoftErrorLimit<br />
|zimbraMtaStpdSoftErrorLimit<br />
|postfix_smtpd_soft_error_limit<br />
|-<br />
|in_flow_delay<br />
|zimbraMtaInFlowDelay<br />
|zimbraMtaInFlowDelay<br />
|postfix_in_flow_delay<br />
|-<br />
|import_environment<br />
|zimbraMtaImportEnvironment<br />
|zimbraMtaImportEnvironment<br />
|postfix_import_environment<br />
|-<br />
|queue_run_delay<br />
|zimbraMtaQueueRunDelay<br />
|zimbraMtaQueueRunDelay<br />
|postfix_queue_run_delay<br />
|-<br />
|minimal_backoff_time<br />
|zimbraMtaMinimalBackoffTime<br />
|zimbraMtaMinimalBackoffTime<br />
|postfix_minimal_backoff_time<br />
|-<br />
|maximal_backoff_time<br />
|zimbraMtaMaximalBackoffTime<br />
|zimbraMtaMaximalBackoffTime<br />
|postfix_maximal_backoff_time<br />
|-<br />
|lmtp_connection_cache_destinations<br />
|zimbraMtaLmtpConnectionCacheDestinations<br />
|zimbraMtaLmtpConnectionCacheDestinations<br />
|postfix_lmtp_connection_cache_destinations<br />
|-<br />
|lmtp_connection_cache_time_limit<br />
|zimbraMtaLmtpConnectionCacheTimeLimit<br />
|zimbraMtaLmtpConnectionCacheTimeLimit<br />
|postfix_lmtp_connection_cache_time_limit<br />
|-<br />
|lmtp_host_lookup<br />
|zimbraMtaLmtpHostLookup<br />
|zimbraMtaLmtpHostLookup<br />
|postfix_lmtp_host_lookup<br />
|-<br />
|transport_maps<br />
|zimbraMtaTransportMaps<br />
|zimbraMtaTransportMaps<br />
|postfix_transport_maps<br />
|-<br />
|propagate_unmatched_extensions<br />
|zimbraMtaPropagateUnmatchedExtensions<br />
|zimbraMtaPropagateUnmatchedExtensions<br />
|postfix_propagate_unmatched_extensions<br />
|-<br />
|virtual_alias_domains<br />
|zimbraMtaVirtualAliasDomains<br />
|zimbraMtaVirtualAliasDomains<br />
|postfix_virtual_alias_domains<br />
|-<br />
|virtual_alias_expansion_limit<br />
|zimbraMtaVirtualAliasExpansionLimit<br />
|zimbraMtaVirtualAliasExpansionLimit<br />
|postfix_virtual_alias_expansion_limit<br />
|-<br />
|virtual_alias_maps<br />
|zimbraMtaVirtualAliasMaps<br />
|zimbraMtaVirtualAliasMaps<br />
|postfix_virtual_alias_maps<br />
|-<br />
|virtual_mailbox_domains<br />
|zimbraMtaVirtualMailboxDomains<br />
|zimbraMtaVirtualMailboxDomains<br />
|postfix_virtual_mailbox_domains<br />
|-<br />
|virtual_mailbox_maps<br />
|zimbraMtaVirtualMailboxMaps<br />
|zimbraMtaVirtualMailboxMaps<br />
|postfix_virtual_mailbox_maps<br />
|-<br />
|virtual_transport<br />
|zimbraMtaSmtpdVirtualTransport<br />
|zimbraMtaSmtpdVirtualTransport<br />
|postfix_virtual_transport<br />
|-<br />
|always_add_missing_headers<br />
|zimbraMtaAlwaysAddMissingHeaders<br />
|zimbraMtaAlwaysAddMissingHeaders<br />
|postfix_always_add_missing_headers<br />
|-<br />
|smtpd_sasl_security_options<br />
|zimbraMtaSmtpdSaslSecurityOptions<br />
|zimbraMtaSmtpdSaslSecurityOptions<br />
|postfix_smtpd_sasl_security_options<br />
|-<br />
|smtpd_sasl_tls_security_options<br />
|zimbraMtaSmtpdSaslTlsSecurityOptions<br />
|zimbraMtaSmtpdSaslTlsSecurityOptions<br />
|postfix_smtpd_sasl_tls_security_options<br />
|-<br />
|smtp_helo_name<br />
|zimbraMtaSmtpHeloName<br />
|zimbraMtaSmtpHeloName<br />
|postfix_smtp_helo_name<br />
|-<br />
|smtp_cname_overrides_servername<br />
|zimbraMtaSmtpCnameOverridesServername<br />
|zimbraMtaSmtpCnameOverridesServername<br />
|postfix_smtp_cname_overrides_servername<br />
|-<br />
|smtp_sasl_auth_enable<br />
|zimbraMtaSmtpSaslAuthEnable<br />
|zimbraMtaSmtpSaslAuthEnable<br />
|postfix_smtp_sasl_auth_enable<br />
|-<br />
|smtp_sasl_security_options<br />
|zimbraMtaSmtpSaslSecurityOptions<br />
|zimbraMtaSmtpSaslSecurityOptions<br />
|postfix_smtp_sasl_security_options<br />
|-<br />
|smtp_tls_CAfile<br />
|zimbraMtaSmtpTlsCAfile<br />
|zimbraMtaSmtpTlsCAfile<br />
|N/A<br />
|-<br />
|smtp_tls_CApath<br />
|zimbraMtaSmtpTlsCApath<br />
|zimbraMtaSmtpTlsCApath<br />
|N/A<br />
|-<br />
|tls_append_default_CA<br />
|zimbraMtaTlsAppendDefaultCA<br />
|zimbraMtaTlsAppendDefaultCA<br />
|N/A<br />
|-<br />
|smtp_tls_security_level<br />
|zimbraMtaSmtpTlsSecurityLevel<br />
|zimbraMtaSmtpTlsSecurityLevel<br />
|postfix_smtp_tls_security_level<br />
|-<br />
|smtp_tls_loglevel<br />
|zimbraMtaSmtpTlsLoglevel<br />
|zimbraMtaSmtpTlsLoglevel<br />
|N/A<br />
|-<br />
|smtp_tls_ciphers<br />
|zimbraMtaSmtpTlsCiphers<br />
|zimbraMtaSmtpTlsCiphers<br />
|N/A<br />
|-<br />
|smtp_tls_mandatory_ciphers<br />
|zimbraMtaSmtpTlsMandatoryCiphers<br />
|zimbraMtaSmtpTlsMandatoryCiphers<br />
|N/A<br />
|-<br />
|smtp_sasl_mechanism_filter<br />
|zimbraMtaSmtpSaslMechanismFilter<br />
|zimbraMtaSmtpSaslMechanismFilter<br />
|postfix_smtp_sasl_mechanism_filter<br />
|-<br />
|smtp_sasl_password_maps<br />
|zimbraMtaSmtpSaslPasswordMaps<br />
|zimbraMtaSmtpSaslPasswordMaps<br />
|postfix_smtp_sasl_password_maps<br />
|-<br />
|milter_connect_timeout<br />
|zimbraMtaMilterConnectTimeout<br />
|zimbraMtaMilterConnectTimeout<br />
|postfix_milter_connect_timeout<br />
|-<br />
|milter_command_timeout<br />
|zimbraMtaMilterCommandTimeout<br />
|zimbraMtaMilterCommandTimeout<br />
|postfix_milter_command_timeout<br />
|-<br />
|milter_content_timeout<br />
|zimbraMtaMilterContentTimeout<br />
|zimbraMtaMilterContentTimeout<br />
|postfix_milter_content_timeout<br />
|-<br />
|milter_default_action<br />
|zimbraMtaMilterDefaultAction<br />
|zimbraMtaMilterDefaultAction<br />
|postfix_milter_default_action<br />
|-<br />
|inet_protocols<br />
|zimbraPostconfProtocol<br />
|zimbraPostconfProtocol<br />
|zimbraPostconfProtocol<br />
|-<br />
|unverified_recipient_defer_code<br />
|zimbraMtaUnverifiedRecipientDeferCode<br />
|zimbraMtaUnverifiedRecipientDeferCode<br />
|N/A<br />
|-<br />
|address_verify_poll_count<br />
|zimbraMtaAddressVerifyPollCount<br />
|zimbraMtaAddressVerifyPollCount<br />
|N/A<br />
|-<br />
|address_verify_poll_delay<br />
|zimbraMtaAddressVerifyPollDelay<br />
|zimbraMtaAddressVerifyPollDelay<br />
|N/A<br />
|-<br />
|address_verify_negative_refresh_time<br />
|zimbraMtaAddressVerifyNegativeRefreshTime<br />
|zimbraMtaAddressVerifyNegativeRefreshTime<br />
|N/A<br />
|-<br />
|address_verify_positive_refresh_time<br />
|zimbraMtaAddressVerifyPositiveRefreshTime<br />
|zimbraMtaAddressVerifyPositiveRefreshTime<br />
|N/A<br />
|}<br />
{{Article Footer|Zimbra Collaboration Suite 9.0, 8.6, 8.5|08/4/2014}}</div>Publiskihttps://wiki.zimbra.com/index.php?title=Anti-spam_Strategies&diff=65271Anti-spam Strategies2018-04-04T12:33:18Z<p>Publiski: </p>
<hr />
<div>{{BC|Community Sandbox}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
= Anti-spam Strategies =<br />
{{KB|{{Unsupported}}|{{ZCS 8.8}}|{{ZCS 8.7}}|{{ZCS 8.0}}|}}<br />
{{WIP}}<br />
== Anti-spam Strategies ==<br />
=== Customizing SpamAssassin ===<br />
<br />
==== ZCS 8.5 and later ====<br />
For ZCS 8.5, SpamAssassin layout has been corrected as per the SpamAssassin developers. '''sauser.cf''' is migrated to the '''/opt/zimbra/data/spamassassin/localrules''' directory. This is the supported location for doing customizations of SpamAssassin for ZCS 8.5 and later.<br />
<br />
==== ZCS 8 ====<br />
For ZCS 8.0, SpamAssassin scans for all *.cf files in '''/opt/zimbra/conf/sa''' and loads them <br />
in alphabetical order. If you create a '''sauser.cf''' file, it will be <br />
loaded after salocal.cf is loaded. This is the supported method for doing <br />
customizations of SpamAssassin for ZCS 8. Note that '''only''' the sauser.cf file will be migrated when upgrading to later releases.<br />
<br />
In 8.0.5, two options were added to the product to enable SpamAssassin rule updates via sa-update (reference: see [https://bugzilla.zimbra.com/show_bug.cgi?id=82201 82201]):<br />
<br />
* '''antispam_enable_rule_updates'''<br />
* '''antispam_enable_restarts'''<br />
<br />
Check that these are set to true, and if not, set them to true and restart amavisd and the MTA:<br />
<br />
$ zmlocalconfig antispam_enable_rule_updates<br />
antispam_enable_rule_updates = false<br />
$ zmlocalconfig antispam_enable_restarts<br />
antispam_enable_restarts = false<br />
<br />
$ zmlocalconfig -e antispam_enable_rule_updates=true<br />
$ zmlocalconfig -e antispam_enable_restarts=true<br />
<br />
$ zmamavisdctl restart<br />
$ zmmtactl restart<br />
<br />
==== ZCS 6 and ZCS 7 ====<br />
For ZCS 6 and ZCS 7, SpamAssassin customizations go in '''/opt/zimbra/conf/sauser.cf'''. When upgrading to ZCS 8 the file will be relocated to '''/opt/zimbra/conf/sa'''<br />
<br />
==== Automatic rule updates ====<br />
With ZCS 8 and later, it is possible to enable automatic rule updates for SpamAssassin to help improve scoring. There are two localconfig keys that control the automatic update behavior.<br />
<br />
* '''antispam_enable_rule_updates''' controls whether or not to enable automatic rule updates. Defaults to '''false'''.<br />
* '''antispam_enable_restarts''' controls whether or not Amavisd will be automatically restarted after a rule update if they are enabled. Defaults to '''false'''.<br />
<br />
==== Automatic rule compilation ====<br />
With ZCS 8.5 and later, it is possible to enable automatic rule compilation when automatic updates are enabled. Compiling the SA rules helps decrease the amount of time it takes to score email. This is controlled via a localconfig key.<br />
<br />
* '''antispam_enable_rule_compilation''' controls whether or not to automatically compile new rules that are automatically updated. Defaults to '''false'''.<br />
<br />
= Customizing Postfix =<br />
In ZCS 7 and ZCS 8, customizing Postfix is a mix of zmlocalconfig and zmprov settings. In ZCS 8.5, virtually all settings are done via zmprov (zmlocalconfig settings will be migrated on upgrade if they do not match the default value).<br />
<br />
zmprov/zmlocalconfig are both permissible and the recommended way to perform Postfix customizations for supported keys.<br />
<br />
For example:<br />
<br />
zmprov ms <server> +zimbraMtaRestriction reject_unknown_reverse_client_hostname<br />
<br />
= Specific Suggested Tweaks =<br />
''Last update 24 October 2014 by L. Mark Stone, Reliable Networks''<br />
<br />
Our client base is very nervous about spam-delivered malware but even more concerned about "false-positives" i.e. legitimate email incorrectly identified as spam. Consequently, we've had to develop tweaks to improve Zimbra's default SpamAssassin configurations. The results have been that users with very public email addresses who typically receive several hundred to more than a thousand emails per day will see no more than ~3 spam emails per day in their Inbox. In our experience, anything less than that and you are likely to wind up with false positives.<br />
<br />
If your end-user base is more tolerant of false positives, then you can tighten things up. <br />
<br />
Keep in mind that Zimbra's Postfix takes a cut at filtering the email stream before Zimbra's SpamAssassin, and that SpamAssassin's processing of emails is much more resource intensive than Postfix's. Consequently, any filtering that you can do at the Postfix level to block emails outright will be helpful in both blocking spam and lowering resource utilization on your Zimbra server. Just be careful of inducing false positives! <br />
<br />
==== DNS Tweaks ====<br />
Zimbra recommends using a caching DNS server locally, and we like BIND9 but DNSMasq is fine as well. (As we understand it, Zimbra may start shipping a DNS server bundled with Zimbra in a later release.)<br />
<br />
One configuration nuance to DNS is the use of forwarders in your BIND9 configuration. We have seen many Zimbra systems use their ISP's, or Google's public DNS servers as forwarders. The problem is that many of the RBL services embedded in SpamAssassin and configurable within Zimbra limit the number/rate of queries they accept from a particular DNS server. Since almost all RBL queries will never be cached, the queries get done by the forwarders. And since the forwarders are doing the same queries for lots of other folks, those queries are often blocked.<br />
<br />
We therefore recommend that when using a local caching DNS server that you ensure the configuration has current hints for the root servers and that the forwarders section in the BIND9 config file be set to empty.<br />
<br />
==== Postfix Tweaks ====<br />
<br />
===== RBLs =====<br />
At the Postfix level we use just a few complementary and conservative RBLs, one DNS check and one Protocol check. All of these can be configured via the Admin Console: (Global Settings > MTA). A list of RBLs can be found at https://en.wikipedia.org/wiki/Comparison_of_DNS_blacklists<br />
<br />
The RBLs we use are:<br />
zen.spamhaus.org psbl.surriel.com b.barracudacentral.org<br />
<br />
Additional RBLs used by zimbra are:<br />
bl.spamcop.net<br />
<br />
The Client RHSBLs we use are (updated June 2, 2014):<br />
dbl.spamhaus.org multi.uribl.com multi.surbl.org<br />
<br />
Additional Client RHSBLs used by Zimbra:<br />
rhsbl.sorbs.net<br />
<br />
Sender RHSBLs used by Zimbra:<br />
multi.uribl.com multi.surbl.org rhsbl.sorbs.net dbl.spamhaus.org<br />
<br />
Reverse Client RHSBLs used by Zimbra:<br />
dbl.spamhaus.org<br />
<br />
Adding RBL and RHSBLs checks in postfix can also be done via the command line.<br />
<br />
For RBLs:<br />
zmprov mcf +zimbraMtaRestriction "reject_rbl_client zen.spamhaus.org"<br />
<br />
For RHSBL clients:<br />
zmprov mcf +zimbraMtaRestriction "reject_rhsbl_client dbl.spamhaus.org"<br />
<br />
On the same Admin Console page we also enable (and leave the remaining Protocol and DNS checks disabled):<br />
* '''reject_non_fqdn_sender'''<br />
* '''reject_unknown_sender_domain''' (Note this setting will be updated in 8.0.5)<br />
<br />
On that same page we also make sure disable "Add X-Originating-IP to messages" as this can block email from remote users with fat email clients like Outlook and Thunderbird on home and public networks like Internet cafes (ZWC clients are unaffected by this.)<br />
<br />
===== fqrdns.pcre from GitHub =====<br />
<br />
Hardware Freak.com maintains a PCRE listing of bad IP ranges to be rejected. This generally rejects larges amounts of bot traffic where the bots are sending out email directly rather than an authenticated user going through the ISP outgoing SMTP servers. Support for using this PCRE method is built into ZCS 8.7 and later.<br />
<br />
cd /opt/zimbra/conf<br />
wget https://raw.githubusercontent.com/stevejenkins/hardwarefreak.com-fqrdns.pcre/master/fqrdns.pcre<br />
zmprov mcf +zimbraMtaRestriction 'check_reverse_client_hostname_access pcre:/opt/zimbra/conf/fqrdns.pcre'<br />
<br />
===== Postscreen =====<br />
<br />
Postscreen is a pre-screening process at the MTA level that can be used to reject spammers by doing additive scoring from a variety of sites. Support for postscreen has been added for ZCS 8.7. Full configuration details will be added to this wiki prior to release.<br />
<br />
==== SpamAssassin Tweaks via the Commandline ====<br />
Our current recommended SpamAssassin customizations comprise three complementary methods:<br />
# Increase the log level reported by Amavis to get clarity from SpamAssassin on why/how spam is being blocked and getting through.<br />
# Put Amavis's temporary directory on a RAM disk to speed up processing.<br />
# Tweak the scores for a few selected individual SpamAssassin tests after installing Pyzor and Razor2.<br />
<br />
===== 1. Increase Amavis's Log Level =====<br />
We found that increasing the log level from 1 to 2 puts in /var/log/zimbra.log the specific SpamAssassin tests which each email has triggered.<br />
<br />
Customizing the Amavis Loglevel is supported in ZCS 8.0.5 and later:<br />
<br />
zmprov mcf zimbraAmavisLogLevel 2<br />
<br />
If you are on an earlier release, this can be achieved by editing /opt/zimbra/conf/amavisd.conf.in. You will need to change the file's permissions to be writable, edit the file, then change the permissions back. Probably a good idea to make a backup copy of the file first... The final edit should should look like this:<br />
<br />
$log_level = 2; # verbosity 0..5 - 1 is the minimum for msg tracing<br />
<br />
Restart amavis for the change to take effect (zmavavisdctl restart). If you are on ZCS 8.0.5 or later, zmconfigd will automatically restart Amavis for you if you change the loglevel.<br />
<br />
Now when an email is marked as spam and an end user asks you "Why?", you can grep /var/log/zimbra.log and find out exactly why. Note the sender and recipient email addresses in the actual log file snippet below have been altered for privacy (lines wrapped for readability):<br />
<br />
Nov 26 13:55:02 mail2 amavis[19107]: (19107-13) SPAM, <comsumer_health@spamsender.com> -> <masked_recipient@example.com>,<br />
Yes, score=17.071 tag=-10 tag2=3.8 kill=16 tests=[BAYES_99=4, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5,<br />
RAZOR2_CF_RANGE_E8_51_100=1.886, RAZOR2_CHECK=2.75, RDNS_NONE=3.5, SPF_PASS=-0.001, T_HK_NAME_DR=0.01, URIBL_BLACK=2.725,<br />
URIBL_DBL_SPAM=1.7] autolearn=spam<br />
<br />
ZCS 8 logs (lines wrapped for readability):<br />
Apr 21 13:55:54 edge01 amavis[32619]: (32619-05) spam-tag, <DrOz@spamsender.us> -> <masked_recipient@example.com>,<br />
Yes, score=9.014 tagged_above=-10 required=3 tests=[BAYES_40=-0.001, DIGEST_MULTIPLE=0.293, DKIM_SIGNED=0.1,<br />
HTML_IMAGE_ONLY_32=0.001, HTML_IMAGE_RATIO_06=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, PYZOR_CHECK=2.75,<br />
RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.886, RAZOR2_CHECK=2.75, T_DKIM_INVALID=0.01]<br />
autolearn=no autolearn_force=no<br />
<br />
In the above example you can see that the sending server has no PTR (Reverse DNS record) and has already been reported to Razor.<br />
<br />
===== 2. Put Amavis's Temp Dir on a RAM Disk =====<br />
We have seen even with fast RAID10 arrays that Amavis's processing an email with large attachments through SpamAssassin can take as long as 10-20 seconds. Putting Amavis'd temp directory on a RAM disk cuts this down to 1-2 seconds. Ralf Hildebrandt's book on Postfix has a section describing how to size the RAM disk, and why this is entirely safe for mail flow even in the event of a server crash. After you've done the homework for sizing, all you need to do is:<br />
<br />
# Stop amavis, mount the RAM disk, start amavis and then edit /etc/fstab to make the change permanent.<br />
<br />
An /etc/fstab entry for a 1GB RAM disks on the server therefore looks like:<br />
<br />
$ grep amavis /etc/fstab<br />
tmpfs /opt/zimbra/data/amavisd/tmp tmpfs defaults,noexec,nodev,nosuid,size=1024m,mode=750,uid=zimbra,gid=zimbra 0 0<br />
<br />
===== 3. Tweak Selected SpamAssasin Scores After Installing Pyzor and Razor2 =====<br />
<br />
= How to install Razor and Pyzor =<br />
== Installing Razor and Pyzor on Ubuntu ==<br />
aptitude install razor pyzor<br />
<br />
==Installing Razor and Pyzor on RHEL6/CentOS6 ==<br />
Create /etc/yum.repos.d/epel.repo<br />
[epel]<br />
name=EPEL repository<br />
baseurl=http://mirrors.kernel.org/fedora-epel/6/x86_64<br />
enabled=1<br />
gpgcheck=0<br />
<br />
yum update<br />
yum install pyzor perl-Razor-Agent<br />
<br />
== Configuring Pyzor ==<br />
As the zimbra user<br />
pyzor --homedir /opt/zimbra/data/amavisd/.pyzor discover<br />
<br />
Update /opt/zimbra/conf/sa/sauser.cf<br />
<br />
# pyzor<br />
use_pyzor 1<br />
pyzor_path /usr/bin/pyzor<br />
# DNS lookups for pyzor can time out easily. Set the following line IF you want to give pyzor up to 20 seconds to respond<br />
# may slow down email delivery<br />
pyzor_timeout 20<br />
<br />
== Configuring Razor ==<br />
As the zimbra user<br />
<br />
razor-admin -home=/opt/zimbra/data/amavisd/.razor -create<br />
razor-admin -home=/opt/zimbra/data/amavisd/.razor -discover<br />
razor-admin -home=/opt/zimbra/data/amavisd/.razor -register -user postmaster@yourdomain.com<br />
<br />
Update /opt/zimbra/conf/sa/sauser.cf<br />
<br />
# razor<br />
use_razor2 1<br />
<br />
== Update SpamAssassin scoring ==<br />
After installing Pyzor and Razor2 and restarting Zimbra's Amavis to make sure these modules are loaded by SpamAssassin, Reliable Networks adds custom (higher) scoring for certain SpamAssassin tests to the appropriate custom SpamAssassin configuration file, which on ZCS 8 should be /opt/zimbra/conf/sa/sauser.cf. Our complete sauser.cf now looks like this (as of September 3, 2014):<br />
<br />
pyzor_timeout 10<br />
use_razor2 1<br />
use_pyzor 1<br />
score URIBL_BLACK 3.250<br />
score RAZOR2_CHECK 3.250<br />
score PYZOR_CHECK 3.250<br />
score BAYES_99 4.000<br />
score BAYES_60 2.250<br />
score BAYES_50 1.500<br />
score BAYES_00 -0.500<br />
score RP_MATCHES_RCVD -0.000<br />
<br />
Then as the '''zimbra''' user, run "zmantispamctl restart ; zmmtactl restart" to restart and load the new scores. The RP_MATCHES_RCVD score is normally -1.713, but we have found that many spammers using cloud servers have DNS and mail forwarding set to RFC standards, and that their emails then get a bump in good reputation from the default score on this test specifically.<br />
<br />
We have found that increasing the scores of the above selected SpamAssassin scores blocks a lot of spam that would otherwise get through.<br />
<br />
= 4. Add custom rules from Kevin McGrail to your scores =<br />
As zimbra user:<br />
<br />
* 8.0 and previous:<br />
<br />
cd /opt/zimbra/conf/sa<br />
wget -N https://www.pccc.com/downloads/SpamAssassin/contrib/KAM.cf -O sakam.cf<br />
zmamavisdctl restart<br />
<br />
* 8.5 and later:<br />
<br />
cd /opt/zimbra/data/spamassassin/localrules<br />
wget -N https://www.pccc.com/downloads/SpamAssassin/contrib/KAM.cf -O sakam.cf<br />
zmamavisdctl restart<br />
<br />
= 5. Enable DCC =<br />
The source for DCC can be obtained from https://www.dcc-servers.net/dcc/. Please read the restrictions and limitations carefully. In particular, it is important to keep in mind that DCC just marks whether something is bulk mail or not, and will tag completely legitimate bulk mailings.<br />
<br />
After downloading and extracting the source, as the '''zimbra''' user, you will need to build it. It will take several tools (gcc, make, wget, etc).<br />
<br />
There is some setup to be done as '''root''' initially. This is assuming using version 1.3.154 of dcc, adjust as necessary:<br />
<br />
# mkdir -p /opt/zimbra/dcc-1.3.154<br />
# chown zimbra:zimbra /opt/zimbra/dcc-1.3.154<br />
# cd /opt/zimbra;ln -s dcc-1.3.154 dcc<br />
<br />
Now, as '''zimbra''' we need to build the software. Here's an example of downloading, extracting, and building:<br />
<br />
[zimbra@host]$ cd /tmp<br />
[zimbra@host]$ mkdir dcc<br />
[zimbra@host]$ wget https://www.dcc-servers.net/dcc/source/dcc.tar.Z<br />
[zimbra@host]$ tar xfz dcc.tar.Z<br />
[zimbra@host]$ cd dcc-1.3.154<br />
[zimbra@host]$ ./configure --homedir=/opt/zimbra/dcc-1.3.154 \<br />
--disable-sys-inst --with-uid=zimbra --disable-server \<br />
--disable-dccifd --disable-dccm \<br />
--with-updatedcc_pfile=/opt/zimbra/data/dcc \<br />
--with-rundir=/opt/zimbra/data/dcc/run \<br />
--bindir=/opt/zimbra/dcc-1.3.154/bin<br />
[zimbra@host]$ make<br />
[zimbra@host]$ make install<br />
[zimbra@host]$ cd /opt/zimbra/data<br />
[zimbra@host data]$ mkdir -p dcc/run<br />
<br />
As the '''zimbra''' user, update '''sauser.cf''' as appropriate for your Zimbra version:<br />
<br />
use_dcc 1<br />
dcc_path /opt/zimbra/dcc/bin/dccproc<br />
<br />
For ZCS 8.0 and earlier, you will need to enable the dcc module by modifying the '''v310.pre''' file from SpamAssassin.<br />
Find the line that looks like:<br />
#loadplugin Mail::SpamAssassin::Plugin::DCC<br />
<br />
and uncomment it (remove the # sign)<br />
<br />
Last, but not least, restart amavis to pick up the changes:<br />
<br />
[zimbra@host]$ zmamavisdctl restart<br />
<br />
= DNSWL registration =<br />
Register your MTAs with DNSWL: https://www.dnswl.org/selfservice/<br />
<br />
= Other notes =<br />
<br />
As we make updates to our own configurations, we will endeavor to keep this page updated as well.<br />
{{Article Footer|Zimbra Collaboration 8.0, 7.0|04/16/2014}}</div>Publiskihttps://wiki.zimbra.com/index.php?title=Anti-spam_Strategies&diff=63341Anti-spam Strategies2017-03-12T22:42:31Z<p>Publiski: /* 4. Add custom rules from Kevin McGrail to your scores */</p>
<hr />
<div>{{BC|Community Sandbox}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
= Anti-spam Strategies =<br />
{{KB|{{Unsupported}}|{{ZCS 8.0}}|{{ZCS 7.0}}|}}<br />
{{WIP}}<br />
== Anti-spam Strategies ==<br />
=== Customizing SpamAssassin ===<br />
<br />
==== ZCS 8.5 and later ====<br />
For ZCS 8.5, SpamAssassin layout has been corrected as per the SpamAssassin developers. '''sauser.cf''' is migrated to the '''/opt/zimbra/data/spamassassin/localrules''' directory. This is the supported location for doing customizations of SpamAssassin for ZCS 8.5 and later.<br />
<br />
==== ZCS 8 ====<br />
For ZCS 8.0, SpamAssassin scans for all *.cf files in '''/opt/zimbra/conf/sa''' and loads them <br />
in alphabetical order. If you create a '''sauser.cf''' file, it will be <br />
loaded after salocal.cf is loaded. This is the supported method for doing <br />
customizations of SpamAssassin for ZCS 8. Note that '''only''' the sauser.cf file will be migrated when upgrading to later releases.<br />
<br />
In 8.0.5, two options were added to the product to enable SpamAssassin rule updates via sa-update (reference: see [https://bugzilla.zimbra.com/show_bug.cgi?id=82201 82201]):<br />
<br />
* '''antispam_enable_rule_updates'''<br />
* '''antispam_enable_restarts'''<br />
<br />
Check that these are set to true, and if not, set them to true and restart amavisd and the MTA:<br />
<br />
$ zmlocalconfig antispam_enable_rule_updates<br />
antispam_enable_rule_updates = false<br />
$ zmlocalconfig antispam_enable_restarts<br />
antispam_enable_restarts = false<br />
<br />
$ zmlocalconfig -e antispam_enable_rule_updates=true<br />
$ zmlocalconfig -e antispam_enable_restarts=true<br />
<br />
$ zmamavisdctl restart<br />
$ zmmtactl restart<br />
<br />
==== ZCS 6 and ZCS 7 ====<br />
For ZCS 6 and ZCS 7, SpamAssassin customizations go in '''/opt/zimbra/conf/sauser.cf'''. When upgrading to ZCS 8 the file will be relocated to '''/opt/zimbra/conf/sa'''<br />
<br />
==== Automatic rule updates ====<br />
With ZCS 8 and later, it is possible to enable automatic rule updates for SpamAssassin to help improve scoring. There are two localconfig keys that control the automatic update behavior.<br />
<br />
* '''antispam_enable_rule_updates''' controls whether or not to enable automatic rule updates. Defaults to '''false'''.<br />
* '''antispam_enable_restarts''' controls whether or not Amavisd will be automatically restarted after a rule update if they are enabled. Defaults to '''false'''.<br />
<br />
==== Automatic rule compilation ====<br />
With ZCS 8.5 and later, it is possible to enable automatic rule compilation when automatic updates are enabled. Compiling the SA rules helps decrease the amount of time it takes to score email. This is controlled via a localconfig key.<br />
<br />
* '''antispam_enable_rule_compilation''' controls whether or not to automatically compile new rules that are automatically updated. Defaults to '''false'''.<br />
<br />
= Customizing Postfix =<br />
In ZCS 7 and ZCS 8, customizing Postfix is a mix of zmlocalconfig and zmprov settings. In ZCS 8.5, virtually all settings are done via zmprov (zmlocalconfig settings will be migrated on upgrade if they do not match the default value).<br />
<br />
zmprov/zmlocalconfig are both permissible and the recommended way to perform Postfix customizations for supported keys.<br />
<br />
For example:<br />
<br />
zmprov ms <server> +zimbraMtaRestriction reject_unknown_reverse_client_hostname<br />
<br />
= Specific Suggested Tweaks =<br />
''Last update 24 October 2014 by L. Mark Stone, Reliable Networks''<br />
<br />
Our client base is very nervous about spam-delivered malware but even more concerned about "false-positives" i.e. legitimate email incorrectly identified as spam. Consequently, we've had to develop tweaks to improve Zimbra's default SpamAssassin configurations. The results have been that users with very public email addresses who typically receive several hundred to more than a thousand emails per day will see no more than ~3 spam emails per day in their Inbox. In our experience, anything less than that and you are likely to wind up with false positives.<br />
<br />
If your end-user base is more tolerant of false positives, then you can tighten things up. <br />
<br />
Keep in mind that Zimbra's Postfix takes a cut at filtering the email stream before Zimbra's SpamAssassin, and that SpamAssassin's processing of emails is much more resource intensive than Postfix's. Consequently, any filtering that you can do at the Postfix level to block emails outright will be helpful in both blocking spam and lowering resource utilization on your Zimbra server. Just be careful of inducing false positives! <br />
<br />
==== DNS Tweaks ====<br />
Zimbra recommends using a caching DNS server locally, and we like BIND9 but DNSMasq is fine as well. (As we understand it, Zimbra may start shipping a DNS server bundled with Zimbra in a later release.)<br />
<br />
One configuration nuance to DNS is the use of forwarders in your BIND9 configuration. We have seen many Zimbra systems use their ISP's, or Google's public DNS servers as forwarders. The problem is that many of the RBL services embedded in SpamAssassin and configurable within Zimbra limit the number/rate of queries they accept from a particular DNS server. Since almost all RBL queries will never be cached, the queries get done by the forwarders. And since the forwarders are doing the same queries for lots of other folks, those queries are often blocked.<br />
<br />
We therefore recommend that when using a local caching DNS server that you ensure the configuration has current hints for the root servers and that the forwarders section in the BIND9 config file be set to empty.<br />
<br />
==== Postfix Tweaks ====<br />
<br />
===== RBLs =====<br />
At the Postfix level we use just a few complementary and conservative RBLs, one DNS check and one Protocol check. All of these can be configured via the Admin Console: (Global Settings > MTA). A list of RBLs can be found at https://en.wikipedia.org/wiki/Comparison_of_DNS_blacklists<br />
<br />
The RBLs we use are:<br />
zen.spamhaus.org psbl.surriel.com b.barracudacentral.org<br />
<br />
Additional RBLs used by zimbra are:<br />
bl.spamcop.net<br />
<br />
The Client RHSBLs we use are (updated June 2, 2014):<br />
dbl.spamhaus.org multi.uribl.com multi.surbl.org<br />
<br />
Additional Client RHSBLs used by Zimbra:<br />
rhsbl.sorbs.net<br />
<br />
Sender RHSBLs used by Zimbra:<br />
multi.uribl.com multi.surbl.org rhsbl.sorbs.net dbl.spamhaus.org<br />
<br />
Reverse Client RHSBLs used by Zimbra:<br />
dbl.spamhaus.org<br />
<br />
Adding RBL and RHSBLs checks in postfix can also be done via the command line.<br />
<br />
For RBLs:<br />
zmprov mcf +zimbraMtaRestriction "reject_rbl_client zen.spamhaus.org"<br />
<br />
For RHSBL clients:<br />
zmprov mcf +zimbraMtaRestriction "reject_rhsbl_client dbl.spamhaus.org"<br />
<br />
On the same Admin Console page we also enable (and leave the remaining Protocol and DNS checks disabled):<br />
* '''reject_non_fqdn_sender'''<br />
* '''reject_unknown_sender_domain''' (Note this setting will be updated in 8.0.5)<br />
<br />
On that same page we also make sure disable "Add X-Originating-IP to messages" as this can block email from remote users with fat email clients like Outlook and Thunderbird on home and public networks like Internet cafes (ZWC clients are unaffected by this.)<br />
<br />
===== fqrdns.pcre from GitHub =====<br />
<br />
Hardware Freak.com maintains a PCRE listing of bad IP ranges to be rejected. This generally rejects larges amounts of bot traffic where the bots are sending out email directly rather than an authenticated user going through the ISP outgoing SMTP servers. Support for using this PCRE method is built into ZCS 8.7 and later.<br />
<br />
cd /opt/zimbra/conf<br />
wget https://raw.githubusercontent.com/stevejenkins/hardwarefreak.com-fqrdns.pcre/master/fqrdns.pcre<br />
zmprov mcf +zimbraMtaRestriction 'check_reverse_client_hostname_access pcre:/opt/zimbra/conf/fqrdns.pcre'<br />
<br />
===== Postscreen =====<br />
<br />
Postscreen is a pre-screening process at the MTA level that can be used to reject spammers by doing additive scoring from a variety of sites. Support for postscreen has been added for ZCS 8.7. Full configuration details will be added to this wiki prior to release.<br />
<br />
==== SpamAssassin Tweaks via the Commandline ====<br />
Our current recommended SpamAssassin customizations comprise three complementary methods:<br />
# Increase the log level reported by Amavis to get clarity from SpamAssassin on why/how spam is being blocked and getting through.<br />
# Put Amavis's temporary directory on a RAM disk to speed up processing.<br />
# Tweak the scores for a few selected individual SpamAssassin tests after installing Pyzor and Razor2.<br />
<br />
===== 1. Increase Amavis's Log Level =====<br />
We found that increasing the log level from 1 to 2 puts in /var/log/zimbra.log the specific SpamAssassin tests which each email has triggered.<br />
<br />
Customizing the Amavis Loglevel is supported in ZCS 8.0.5 and later:<br />
<br />
zmprov mcf zimbraAmavisLogLevel 2<br />
<br />
If you are on an earlier release, this can be achieved by editing /opt/zimbra/conf/amavisd.conf.in. You will need to change the file's permissions to be writable, edit the file, then change the permissions back. Probably a good idea to make a backup copy of the file first... The final edit should should look like this:<br />
<br />
$log_level = 2; # verbosity 0..5 - 1 is the minimum for msg tracing<br />
<br />
Restart amavis for the change to take effect (zmavavisdctl restart). If you are on ZCS 8.0.5 or later, zmconfigd will automatically restart Amavis for you if you change the loglevel.<br />
<br />
Now when an email is marked as spam and an end user asks you "Why?", you can grep /var/log/zimbra.log and find out exactly why. Note the sender and recipient email addresses in the actual log file snippet below have been altered for privacy (lines wrapped for readability):<br />
<br />
Nov 26 13:55:02 mail2 amavis[19107]: (19107-13) SPAM, <comsumer_health@spamsender.com> -> <masked_recipient@example.com>,<br />
Yes, score=17.071 tag=-10 tag2=3.8 kill=16 tests=[BAYES_99=4, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5,<br />
RAZOR2_CF_RANGE_E8_51_100=1.886, RAZOR2_CHECK=2.75, RDNS_NONE=3.5, SPF_PASS=-0.001, T_HK_NAME_DR=0.01, URIBL_BLACK=2.725,<br />
URIBL_DBL_SPAM=1.7] autolearn=spam<br />
<br />
ZCS 8 logs (lines wrapped for readability):<br />
Apr 21 13:55:54 edge01 amavis[32619]: (32619-05) spam-tag, <DrOz@spamsender.us> -> <masked_recipient@example.com>,<br />
Yes, score=9.014 tagged_above=-10 required=3 tests=[BAYES_40=-0.001, DIGEST_MULTIPLE=0.293, DKIM_SIGNED=0.1,<br />
HTML_IMAGE_ONLY_32=0.001, HTML_IMAGE_RATIO_06=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, PYZOR_CHECK=2.75,<br />
RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.886, RAZOR2_CHECK=2.75, T_DKIM_INVALID=0.01]<br />
autolearn=no autolearn_force=no<br />
<br />
In the above example you can see that the sending server has no PTR (Reverse DNS record) and has already been reported to Razor.<br />
<br />
===== 2. Put Amavis's Temp Dir on a RAM Disk =====<br />
We have seen even with fast RAID10 arrays that Amavis's processing an email with large attachments through SpamAssassin can take as long as 10-20 seconds. Putting Amavis'd temp directory on a RAM disk cuts this down to 1-2 seconds. Ralf Hildebrandt's book on Postfix has a section describing how to size the RAM disk, and why this is entirely safe for mail flow even in the event of a server crash. After you've done the homework for sizing, all you need to do is:<br />
<br />
# Stop amavis, mount the RAM disk, start amavis and then edit /etc/fstab to make the change permanent.<br />
<br />
An /etc/fstab entry for a 1GB RAM disks on the server therefore looks like:<br />
<br />
$ grep amavis /etc/fstab<br />
tmpfs /opt/zimbra/data/amavisd/tmp tmpfs defaults,noexec,nodev,nosuid,size=1024m,mode=750,uid=zimbra,gid=zimbra 0 0<br />
<br />
===== 3. Tweak Selected SpamAssasin Scores After Installing Pyzor and Razor2 =====<br />
<br />
= How to install Razor and Pyzor =<br />
== Installing Razor and Pyzor on Ubuntu ==<br />
aptitude install razor pyzor<br />
<br />
==Installing Razor and Pyzor on RHEL6/CentOS6 ==<br />
Create /etc/yum.repos.d/epel.repo<br />
[epel]<br />
name=EPEL repository<br />
baseurl=http://mirrors.kernel.org/fedora-epel/6/x86_64<br />
enabled=1<br />
gpgcheck=0<br />
<br />
yum update<br />
yum install pyzor perl-Razor-Agent<br />
<br />
== Configuring Pyzor ==<br />
As the zimbra user<br />
pyzor --homedir /opt/zimbra/data/amavisd/.pyzor discover<br />
<br />
Update /opt/zimbra/conf/sa/sauser.cf<br />
<br />
# pyzor<br />
use_pyzor 1<br />
pyzor_path /usr/bin/pyzor<br />
# DNS lookups for pyzor can time out easily. Set the following line IF you want to give pyzor up to 20 seconds to respond<br />
# may slow down email delivery<br />
pyzor_timeout 20<br />
<br />
== Configuring Razor ==<br />
As the zimbra user<br />
<br />
razor-admin -home=/opt/zimbra/data/amavisd/.razor -create<br />
razor-admin -home=/opt/zimbra/data/amavisd/.razor -discover<br />
razor-admin -home=/opt/zimbra/data/amavisd/.razor -register -user postmaster@yourdomain.com<br />
<br />
Update /opt/zimbra/conf/sa/sauser.cf<br />
<br />
# razor<br />
use_razor2 1<br />
<br />
== Update SpamAssassin scoring ==<br />
After installing Pyzor and Razor2 and restarting Zimbra's Amavis to make sure these modules are loaded by SpamAssassin, Reliable Networks adds custom (higher) scoring for certain SpamAssassin tests to the appropriate custom SpamAssassin configuration file, which on ZCS 8 should be /opt/zimbra/conf/sa/sauser.cf. Our complete sauser.cf now looks like this (as of September 3, 2014):<br />
<br />
pyzor_timeout 10<br />
use_razor2 1<br />
use_pyzor 1<br />
score URIBL_BLACK 3.250<br />
score RAZOR2_CHECK 3.250<br />
score PYZOR_CHECK 3.250<br />
score BAYES_99 4.000<br />
score BAYES_60 2.250<br />
score BAYES_50 1.500<br />
score BAYES_00 -0.500<br />
score RP_MATCHES_RCVD -0.000<br />
<br />
Then as the '''zimbra''' user, run "zmantispamctl restart ; zmmtactl restart" to restart and load the new scores. The RP_MATCHES_RCVD score is normally -1.713, but we have found that many spammers using cloud servers have DNS and mail forwarding set to RFC standards, and that their emails then get a bump in good reputation from the default score on this test specifically.<br />
<br />
We have found that increasing the scores of the above selected SpamAssassin scores blocks a lot of spam that would otherwise get through.<br />
<br />
= 4. Add custom rules from Kevin McGrail to your scores =<br />
As zimbra user:<br />
<br />
* 8.0 and previous:<br />
<br />
cd /opt/zimbra/conf/sa<br />
wget -N https://www.pccc.com/downloads/SpamAssassin/contrib/KAM.cf -O sakam.cf<br />
zmamavisdctl restart<br />
<br />
* 8.5 and later:<br />
<br />
cd /opt/zimbra/data/spamassassin/localrules<br />
wget -N https://www.pccc.com/downloads/SpamAssassin/contrib/KAM.cf -O sakam.cf<br />
zmamavisdctl restart<br />
<br />
= 5. Enable DCC =<br />
The source for DCC can be obtained from https://www.dcc-servers.net/dcc/. Please read the restrictions and limitations carefully. In particular, it is important to keep in mind that DCC just marks whether something is bulk mail or not, and will tag completely legitimate bulk mailings.<br />
<br />
After downloading and extracting the source, as the '''zimbra''' user, you will need to build it. It will take several tools (gcc, make, wget, etc).<br />
<br />
There is some setup to be done as '''root''' initially. This is assuming using version 1.3.154 of dcc, adjust as necessary:<br />
<br />
# mkdir -p /opt/zimbra/dcc-1.3.154<br />
# chown zimbra:zimbra /opt/zimbra/dcc-1.3.154<br />
# cd /opt/zimbra;ln -s dcc-1.3.154 dcc<br />
<br />
Now, as '''zimbra''' we need to build the software. Here's an example of downloading, extracting, and building:<br />
<br />
[zimbra@host]$ cd /tmp<br />
[zimbra@host]$ mkdir dcc<br />
[zimbra@host]$ wget https://www.dcc-servers.net/dcc/source/dcc.tar.Z<br />
[zimbra@host]$ tar xfz dcc.tar.Z<br />
[zimbra@host]$ cd dcc-1.3.154<br />
[zimbra@host]$ ./configure --homedir=/opt/zimbra/dcc-1.3.154 \<br />
--disable-sys-inst --with-uid=zimbra --disable-server \<br />
--disable-dccifd --disable-dccm \<br />
--with-updatedcc_pfile=/opt/zimbra/data/dcc \<br />
--with-rundir=/opt/zimbra/data/dcc/run \<br />
--bindir=/opt/zimbra/dcc-1.3.154/bin<br />
[zimbra@host]$ make<br />
[zimbra@host]$ make install<br />
[zimbra@host]$ cd /opt/zimbra/data<br />
[zimbra@host data]$ mkdir -p dcc/run<br />
<br />
As the '''zimbra''' user, update '''sauser.cf''' as appropriate for your Zimbra version:<br />
<br />
use_dcc 1<br />
dcc_path /opt/zimbra/dcc/bin/dccproc<br />
<br />
For ZCS 8.0 and earlier, you will need to enable the dcc module by modifying the '''v310.pre''' file from SpamAssassin.<br />
Find the line that looks like:<br />
#loadplugin Mail::SpamAssassin::Plugin::DCC<br />
<br />
and uncomment it (remove the # sign)<br />
<br />
Last, but not least, restart amavis to pick up the changes:<br />
<br />
[zimbra@host]$ zmamavisdctl restart<br />
<br />
= DNSWL registration =<br />
Register your MTAs with DNSWL: https://www.dnswl.org/selfservice/<br />
<br />
= Other notes =<br />
<br />
As we make updates to our own configurations, we will endeavor to keep this page updated as well.<br />
{{Article Footer|Zimbra Collaboration 8.0, 7.0|04/16/2014}}</div>Publiskihttps://wiki.zimbra.com/index.php?title=Anti-spam_Strategies&diff=63340Anti-spam Strategies2017-03-12T22:36:13Z<p>Publiski: /* fqrdns.pcre from GitHub */</p>
<hr />
<div>{{BC|Community Sandbox}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
= Anti-spam Strategies =<br />
{{KB|{{Unsupported}}|{{ZCS 8.0}}|{{ZCS 7.0}}|}}<br />
{{WIP}}<br />
== Anti-spam Strategies ==<br />
=== Customizing SpamAssassin ===<br />
<br />
==== ZCS 8.5 and later ====<br />
For ZCS 8.5, SpamAssassin layout has been corrected as per the SpamAssassin developers. '''sauser.cf''' is migrated to the '''/opt/zimbra/data/spamassassin/localrules''' directory. This is the supported location for doing customizations of SpamAssassin for ZCS 8.5 and later.<br />
<br />
==== ZCS 8 ====<br />
For ZCS 8.0, SpamAssassin scans for all *.cf files in '''/opt/zimbra/conf/sa''' and loads them <br />
in alphabetical order. If you create a '''sauser.cf''' file, it will be <br />
loaded after salocal.cf is loaded. This is the supported method for doing <br />
customizations of SpamAssassin for ZCS 8. Note that '''only''' the sauser.cf file will be migrated when upgrading to later releases.<br />
<br />
In 8.0.5, two options were added to the product to enable SpamAssassin rule updates via sa-update (reference: see [https://bugzilla.zimbra.com/show_bug.cgi?id=82201 82201]):<br />
<br />
* '''antispam_enable_rule_updates'''<br />
* '''antispam_enable_restarts'''<br />
<br />
Check that these are set to true, and if not, set them to true and restart amavisd and the MTA:<br />
<br />
$ zmlocalconfig antispam_enable_rule_updates<br />
antispam_enable_rule_updates = false<br />
$ zmlocalconfig antispam_enable_restarts<br />
antispam_enable_restarts = false<br />
<br />
$ zmlocalconfig -e antispam_enable_rule_updates=true<br />
$ zmlocalconfig -e antispam_enable_restarts=true<br />
<br />
$ zmamavisdctl restart<br />
$ zmmtactl restart<br />
<br />
==== ZCS 6 and ZCS 7 ====<br />
For ZCS 6 and ZCS 7, SpamAssassin customizations go in '''/opt/zimbra/conf/sauser.cf'''. When upgrading to ZCS 8 the file will be relocated to '''/opt/zimbra/conf/sa'''<br />
<br />
==== Automatic rule updates ====<br />
With ZCS 8 and later, it is possible to enable automatic rule updates for SpamAssassin to help improve scoring. There are two localconfig keys that control the automatic update behavior.<br />
<br />
* '''antispam_enable_rule_updates''' controls whether or not to enable automatic rule updates. Defaults to '''false'''.<br />
* '''antispam_enable_restarts''' controls whether or not Amavisd will be automatically restarted after a rule update if they are enabled. Defaults to '''false'''.<br />
<br />
==== Automatic rule compilation ====<br />
With ZCS 8.5 and later, it is possible to enable automatic rule compilation when automatic updates are enabled. Compiling the SA rules helps decrease the amount of time it takes to score email. This is controlled via a localconfig key.<br />
<br />
* '''antispam_enable_rule_compilation''' controls whether or not to automatically compile new rules that are automatically updated. Defaults to '''false'''.<br />
<br />
= Customizing Postfix =<br />
In ZCS 7 and ZCS 8, customizing Postfix is a mix of zmlocalconfig and zmprov settings. In ZCS 8.5, virtually all settings are done via zmprov (zmlocalconfig settings will be migrated on upgrade if they do not match the default value).<br />
<br />
zmprov/zmlocalconfig are both permissible and the recommended way to perform Postfix customizations for supported keys.<br />
<br />
For example:<br />
<br />
zmprov ms <server> +zimbraMtaRestriction reject_unknown_reverse_client_hostname<br />
<br />
= Specific Suggested Tweaks =<br />
''Last update 24 October 2014 by L. Mark Stone, Reliable Networks''<br />
<br />
Our client base is very nervous about spam-delivered malware but even more concerned about "false-positives" i.e. legitimate email incorrectly identified as spam. Consequently, we've had to develop tweaks to improve Zimbra's default SpamAssassin configurations. The results have been that users with very public email addresses who typically receive several hundred to more than a thousand emails per day will see no more than ~3 spam emails per day in their Inbox. In our experience, anything less than that and you are likely to wind up with false positives.<br />
<br />
If your end-user base is more tolerant of false positives, then you can tighten things up. <br />
<br />
Keep in mind that Zimbra's Postfix takes a cut at filtering the email stream before Zimbra's SpamAssassin, and that SpamAssassin's processing of emails is much more resource intensive than Postfix's. Consequently, any filtering that you can do at the Postfix level to block emails outright will be helpful in both blocking spam and lowering resource utilization on your Zimbra server. Just be careful of inducing false positives! <br />
<br />
==== DNS Tweaks ====<br />
Zimbra recommends using a caching DNS server locally, and we like BIND9 but DNSMasq is fine as well. (As we understand it, Zimbra may start shipping a DNS server bundled with Zimbra in a later release.)<br />
<br />
One configuration nuance to DNS is the use of forwarders in your BIND9 configuration. We have seen many Zimbra systems use their ISP's, or Google's public DNS servers as forwarders. The problem is that many of the RBL services embedded in SpamAssassin and configurable within Zimbra limit the number/rate of queries they accept from a particular DNS server. Since almost all RBL queries will never be cached, the queries get done by the forwarders. And since the forwarders are doing the same queries for lots of other folks, those queries are often blocked.<br />
<br />
We therefore recommend that when using a local caching DNS server that you ensure the configuration has current hints for the root servers and that the forwarders section in the BIND9 config file be set to empty.<br />
<br />
==== Postfix Tweaks ====<br />
<br />
===== RBLs =====<br />
At the Postfix level we use just a few complementary and conservative RBLs, one DNS check and one Protocol check. All of these can be configured via the Admin Console: (Global Settings > MTA). A list of RBLs can be found at https://en.wikipedia.org/wiki/Comparison_of_DNS_blacklists<br />
<br />
The RBLs we use are:<br />
zen.spamhaus.org psbl.surriel.com b.barracudacentral.org<br />
<br />
Additional RBLs used by zimbra are:<br />
bl.spamcop.net<br />
<br />
The Client RHSBLs we use are (updated June 2, 2014):<br />
dbl.spamhaus.org multi.uribl.com multi.surbl.org<br />
<br />
Additional Client RHSBLs used by Zimbra:<br />
rhsbl.sorbs.net<br />
<br />
Sender RHSBLs used by Zimbra:<br />
multi.uribl.com multi.surbl.org rhsbl.sorbs.net dbl.spamhaus.org<br />
<br />
Reverse Client RHSBLs used by Zimbra:<br />
dbl.spamhaus.org<br />
<br />
Adding RBL and RHSBLs checks in postfix can also be done via the command line.<br />
<br />
For RBLs:<br />
zmprov mcf +zimbraMtaRestriction "reject_rbl_client zen.spamhaus.org"<br />
<br />
For RHSBL clients:<br />
zmprov mcf +zimbraMtaRestriction "reject_rhsbl_client dbl.spamhaus.org"<br />
<br />
On the same Admin Console page we also enable (and leave the remaining Protocol and DNS checks disabled):<br />
* '''reject_non_fqdn_sender'''<br />
* '''reject_unknown_sender_domain''' (Note this setting will be updated in 8.0.5)<br />
<br />
On that same page we also make sure disable "Add X-Originating-IP to messages" as this can block email from remote users with fat email clients like Outlook and Thunderbird on home and public networks like Internet cafes (ZWC clients are unaffected by this.)<br />
<br />
===== fqrdns.pcre from GitHub =====<br />
<br />
Hardware Freak.com maintains a PCRE listing of bad IP ranges to be rejected. This generally rejects larges amounts of bot traffic where the bots are sending out email directly rather than an authenticated user going through the ISP outgoing SMTP servers. Support for using this PCRE method is built into ZCS 8.7 and later.<br />
<br />
cd /opt/zimbra/conf<br />
wget https://raw.githubusercontent.com/stevejenkins/hardwarefreak.com-fqrdns.pcre/master/fqrdns.pcre<br />
zmprov mcf +zimbraMtaRestriction 'check_reverse_client_hostname_access pcre:/opt/zimbra/conf/fqrdns.pcre'<br />
<br />
===== Postscreen =====<br />
<br />
Postscreen is a pre-screening process at the MTA level that can be used to reject spammers by doing additive scoring from a variety of sites. Support for postscreen has been added for ZCS 8.7. Full configuration details will be added to this wiki prior to release.<br />
<br />
==== SpamAssassin Tweaks via the Commandline ====<br />
Our current recommended SpamAssassin customizations comprise three complementary methods:<br />
# Increase the log level reported by Amavis to get clarity from SpamAssassin on why/how spam is being blocked and getting through.<br />
# Put Amavis's temporary directory on a RAM disk to speed up processing.<br />
# Tweak the scores for a few selected individual SpamAssassin tests after installing Pyzor and Razor2.<br />
<br />
===== 1. Increase Amavis's Log Level =====<br />
We found that increasing the log level from 1 to 2 puts in /var/log/zimbra.log the specific SpamAssassin tests which each email has triggered.<br />
<br />
Customizing the Amavis Loglevel is supported in ZCS 8.0.5 and later:<br />
<br />
zmprov mcf zimbraAmavisLogLevel 2<br />
<br />
If you are on an earlier release, this can be achieved by editing /opt/zimbra/conf/amavisd.conf.in. You will need to change the file's permissions to be writable, edit the file, then change the permissions back. Probably a good idea to make a backup copy of the file first... The final edit should should look like this:<br />
<br />
$log_level = 2; # verbosity 0..5 - 1 is the minimum for msg tracing<br />
<br />
Restart amavis for the change to take effect (zmavavisdctl restart). If you are on ZCS 8.0.5 or later, zmconfigd will automatically restart Amavis for you if you change the loglevel.<br />
<br />
Now when an email is marked as spam and an end user asks you "Why?", you can grep /var/log/zimbra.log and find out exactly why. Note the sender and recipient email addresses in the actual log file snippet below have been altered for privacy (lines wrapped for readability):<br />
<br />
Nov 26 13:55:02 mail2 amavis[19107]: (19107-13) SPAM, <comsumer_health@spamsender.com> -> <masked_recipient@example.com>,<br />
Yes, score=17.071 tag=-10 tag2=3.8 kill=16 tests=[BAYES_99=4, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5,<br />
RAZOR2_CF_RANGE_E8_51_100=1.886, RAZOR2_CHECK=2.75, RDNS_NONE=3.5, SPF_PASS=-0.001, T_HK_NAME_DR=0.01, URIBL_BLACK=2.725,<br />
URIBL_DBL_SPAM=1.7] autolearn=spam<br />
<br />
ZCS 8 logs (lines wrapped for readability):<br />
Apr 21 13:55:54 edge01 amavis[32619]: (32619-05) spam-tag, <DrOz@spamsender.us> -> <masked_recipient@example.com>,<br />
Yes, score=9.014 tagged_above=-10 required=3 tests=[BAYES_40=-0.001, DIGEST_MULTIPLE=0.293, DKIM_SIGNED=0.1,<br />
HTML_IMAGE_ONLY_32=0.001, HTML_IMAGE_RATIO_06=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, PYZOR_CHECK=2.75,<br />
RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.886, RAZOR2_CHECK=2.75, T_DKIM_INVALID=0.01]<br />
autolearn=no autolearn_force=no<br />
<br />
In the above example you can see that the sending server has no PTR (Reverse DNS record) and has already been reported to Razor.<br />
<br />
===== 2. Put Amavis's Temp Dir on a RAM Disk =====<br />
We have seen even with fast RAID10 arrays that Amavis's processing an email with large attachments through SpamAssassin can take as long as 10-20 seconds. Putting Amavis'd temp directory on a RAM disk cuts this down to 1-2 seconds. Ralf Hildebrandt's book on Postfix has a section describing how to size the RAM disk, and why this is entirely safe for mail flow even in the event of a server crash. After you've done the homework for sizing, all you need to do is:<br />
<br />
# Stop amavis, mount the RAM disk, start amavis and then edit /etc/fstab to make the change permanent.<br />
<br />
An /etc/fstab entry for a 1GB RAM disks on the server therefore looks like:<br />
<br />
$ grep amavis /etc/fstab<br />
tmpfs /opt/zimbra/data/amavisd/tmp tmpfs defaults,noexec,nodev,nosuid,size=1024m,mode=750,uid=zimbra,gid=zimbra 0 0<br />
<br />
===== 3. Tweak Selected SpamAssasin Scores After Installing Pyzor and Razor2 =====<br />
<br />
= How to install Razor and Pyzor =<br />
== Installing Razor and Pyzor on Ubuntu ==<br />
aptitude install razor pyzor<br />
<br />
==Installing Razor and Pyzor on RHEL6/CentOS6 ==<br />
Create /etc/yum.repos.d/epel.repo<br />
[epel]<br />
name=EPEL repository<br />
baseurl=http://mirrors.kernel.org/fedora-epel/6/x86_64<br />
enabled=1<br />
gpgcheck=0<br />
<br />
yum update<br />
yum install pyzor perl-Razor-Agent<br />
<br />
== Configuring Pyzor ==<br />
As the zimbra user<br />
pyzor --homedir /opt/zimbra/data/amavisd/.pyzor discover<br />
<br />
Update /opt/zimbra/conf/sa/sauser.cf<br />
<br />
# pyzor<br />
use_pyzor 1<br />
pyzor_path /usr/bin/pyzor<br />
# DNS lookups for pyzor can time out easily. Set the following line IF you want to give pyzor up to 20 seconds to respond<br />
# may slow down email delivery<br />
pyzor_timeout 20<br />
<br />
== Configuring Razor ==<br />
As the zimbra user<br />
<br />
razor-admin -home=/opt/zimbra/data/amavisd/.razor -create<br />
razor-admin -home=/opt/zimbra/data/amavisd/.razor -discover<br />
razor-admin -home=/opt/zimbra/data/amavisd/.razor -register -user postmaster@yourdomain.com<br />
<br />
Update /opt/zimbra/conf/sa/sauser.cf<br />
<br />
# razor<br />
use_razor2 1<br />
<br />
== Update SpamAssassin scoring ==<br />
After installing Pyzor and Razor2 and restarting Zimbra's Amavis to make sure these modules are loaded by SpamAssassin, Reliable Networks adds custom (higher) scoring for certain SpamAssassin tests to the appropriate custom SpamAssassin configuration file, which on ZCS 8 should be /opt/zimbra/conf/sa/sauser.cf. Our complete sauser.cf now looks like this (as of September 3, 2014):<br />
<br />
pyzor_timeout 10<br />
use_razor2 1<br />
use_pyzor 1<br />
score URIBL_BLACK 3.250<br />
score RAZOR2_CHECK 3.250<br />
score PYZOR_CHECK 3.250<br />
score BAYES_99 4.000<br />
score BAYES_60 2.250<br />
score BAYES_50 1.500<br />
score BAYES_00 -0.500<br />
score RP_MATCHES_RCVD -0.000<br />
<br />
Then as the '''zimbra''' user, run "zmantispamctl restart ; zmmtactl restart" to restart and load the new scores. The RP_MATCHES_RCVD score is normally -1.713, but we have found that many spammers using cloud servers have DNS and mail forwarding set to RFC standards, and that their emails then get a bump in good reputation from the default score on this test specifically.<br />
<br />
We have found that increasing the scores of the above selected SpamAssassin scores blocks a lot of spam that would otherwise get through.<br />
<br />
= 4. Add custom rules from Kevin McGrail to your scores =<br />
As zimbra user:<br />
<br />
* 8.0 and previous:<br />
<br />
cd /opt/zimbra/conf/sa<br />
wget -N https://www.pccc.com/downloads/SpamAssassin/contrib/KAM.cf -O sakam.cf<br />
zmamavisdctl restart<br />
<br />
* 8.5 and later:<br />
<br />
cd /opt/zimbra/data/spamassassin/localrules<br />
wget -N https://www.pccc.com/downloads/SpamAssassin/contrib/KAM.cf<br />
zmamavisdctl restart<br />
<br />
= 5. Enable DCC =<br />
The source for DCC can be obtained from https://www.dcc-servers.net/dcc/. Please read the restrictions and limitations carefully. In particular, it is important to keep in mind that DCC just marks whether something is bulk mail or not, and will tag completely legitimate bulk mailings.<br />
<br />
After downloading and extracting the source, as the '''zimbra''' user, you will need to build it. It will take several tools (gcc, make, wget, etc).<br />
<br />
There is some setup to be done as '''root''' initially. This is assuming using version 1.3.154 of dcc, adjust as necessary:<br />
<br />
# mkdir -p /opt/zimbra/dcc-1.3.154<br />
# chown zimbra:zimbra /opt/zimbra/dcc-1.3.154<br />
# cd /opt/zimbra;ln -s dcc-1.3.154 dcc<br />
<br />
Now, as '''zimbra''' we need to build the software. Here's an example of downloading, extracting, and building:<br />
<br />
[zimbra@host]$ cd /tmp<br />
[zimbra@host]$ mkdir dcc<br />
[zimbra@host]$ wget https://www.dcc-servers.net/dcc/source/dcc.tar.Z<br />
[zimbra@host]$ tar xfz dcc.tar.Z<br />
[zimbra@host]$ cd dcc-1.3.154<br />
[zimbra@host]$ ./configure --homedir=/opt/zimbra/dcc-1.3.154 \<br />
--disable-sys-inst --with-uid=zimbra --disable-server \<br />
--disable-dccifd --disable-dccm \<br />
--with-updatedcc_pfile=/opt/zimbra/data/dcc \<br />
--with-rundir=/opt/zimbra/data/dcc/run \<br />
--bindir=/opt/zimbra/dcc-1.3.154/bin<br />
[zimbra@host]$ make<br />
[zimbra@host]$ make install<br />
[zimbra@host]$ cd /opt/zimbra/data<br />
[zimbra@host data]$ mkdir -p dcc/run<br />
<br />
As the '''zimbra''' user, update '''sauser.cf''' as appropriate for your Zimbra version:<br />
<br />
use_dcc 1<br />
dcc_path /opt/zimbra/dcc/bin/dccproc<br />
<br />
For ZCS 8.0 and earlier, you will need to enable the dcc module by modifying the '''v310.pre''' file from SpamAssassin.<br />
Find the line that looks like:<br />
#loadplugin Mail::SpamAssassin::Plugin::DCC<br />
<br />
and uncomment it (remove the # sign)<br />
<br />
Last, but not least, restart amavis to pick up the changes:<br />
<br />
[zimbra@host]$ zmamavisdctl restart<br />
<br />
= DNSWL registration =<br />
Register your MTAs with DNSWL: https://www.dnswl.org/selfservice/<br />
<br />
= Other notes =<br />
<br />
As we make updates to our own configurations, we will endeavor to keep this page updated as well.<br />
{{Article Footer|Zimbra Collaboration 8.0, 7.0|04/16/2014}}</div>Publiskihttps://wiki.zimbra.com/index.php?title=ClamAV_-_Updating_clamd_for_releases_earlier_than_ZCS_8.0.6&diff=63105ClamAV - Updating clamd for releases earlier than ZCS 8.0.62016-10-25T06:04:41Z<p>Publiski: /* Update Instructions */</p>
<hr />
<div>{{BC|Certified}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=ClamAV - Updating clamd for releases earlier than ZCS 8.0.6 =<br />
{{KB|{{ZC}}|{{ZCS 8.0}}|{{ZCS 7.0}}||}}<br />
<br />
For those using ZCS 8.0.6 and prior, come 22 October 2016 anti-virus definitions will no longer update AND '''your ClamAV instance will stop working entirely'''.<br />
*EOL Source: http://blog.clamav.net/2016/05/clamav-097-engine-end-of-life.html<br />
<br />
==Preventative methods==<br />
* Update ZCS to a newer version.<br />
* Update just the ClamAV component.<br />
<br />
==Workaround==<br />
Zimbra Collaboration is the open source leader in email and collaboration. That means your company can benefit from the manual upgrade of some third party packages and keep your email server up, running and secure, while planning your upgrade to the latest ZCS Release.<br />
===Disable the antivirus===<br />
You can follow a workaround by disabling antivirus.<br />
This workaround will let your Zimbra Collaboration platform run without antivirus. However, '''we don’t recommend it.'''<br />
====Turn off ClamAV from your Admin Console====<br />
Go to Server > Services 'as/av' tab > uncheck av. <br />
====Via CLI====<br />
Run the next commands as zimbra user (The minus sign is important, or you'll leave nothing but av running.):<br />
zmprov ms `zmhostname` -zimbraServiceEnabled antivirus<br />
zmamavisdctl reload<br />
<br />
===Manual ClamAV component upgrade===<br />
Zimbra includes ClamAV 0.98.4 as of ZCS 8.0.7+. The clamav-0.98.4 directory from an installed ZCS 8.0.7 or later installation can be copied directly to an earlier ZCS 8.0/7.2.x server. To upgrade ClamAV, perform the following steps:<br />
====Downloads====<br />
Use the clamav version our team has generated for your Zimbra environments:<br />
* Redhat 6.x: [https://files.zimbra.com/downloads/clamav/rhel6_64/clamav-0.98.4.tar.gz clamav-0.98.4.tar.gz] [https://files.zimbra.com/downloads/clamav/rhel6_64/clamav-0.98.4.tar.gz.md5 md5] [https://files.zimbra.com/downloads/clamav/rhel6_64/clamav-0.98.4.tar.gz.sha256 sha256]<br><br />
* CentOS 6.x: [https://files.zimbra.com/downloads/clamav/rhel6_64/clamav-0.98.4.tar.gz clamav-0.98.4.tar.gz] [https://files.zimbra.com/downloads/clamav/rhel6_64/clamav-0.98.4.tar.gz.md5 md5] [https://files.zimbra.com/downloads/clamav/rhel6_64/clamav-0.98.4.tar.gz.sha256 sha256]<br> <br />
* SLES 11 64-bit: [https://files.zimbra.com/downloads/clamav/sles11_64/clamav-0.98.4.tar.gz clamav-0.98.4.tar.gz] [https://files.zimbra.com/downloads/clamav/sles11_64/clamav-0.98.4.tar.gz.md5 md5] [https://files.zimbra.com/downloads/clamav/sles11_64/clamav-0.98.4.tar.gz.sha256 sha256]<br><br />
* Ubuntu 10.04 64-bit: [https://files.zimbra.com/downloads/clamav/ubuntu10_64/clamav-0.98.4.tar.gz clamav-0.98.4.tar.gz] [https://files.zimbra.com/downloads/clamav/ubuntu10_64/clamav-0.98.4.tar.gz.md5 md5] [https://files.zimbra.com/downloads/clamav/ubuntu10_64/clamav-0.98.4.tar.gz.sha256 sha256]<br><br />
* Ubuntu 12.06 64-bit: [https://files.zimbra.com/downloads/clamav/ubuntu12_64/clamav-0.98.4.tar.gz clamav-0.98.4.tar.gz] [https://files.zimbra.com/downloads/clamav/ubuntu12_64/clamav-0.98.4.tar.gz.md5 md5] [https://files.zimbra.com/downloads/clamav/ubuntu12_64/clamav-0.98.4.tar.gz.sha256 sha256]<br><br />
<br />
=====Other methods to obtain=====<br />
* Install a new server with a later release of ZCS or use the above links. The Free Open-Source release of ZCS is available at http://www.zimbra.com/downloads/os-downloads.html. This document was tested with 8.5.1 (8.0.9 for Ubuntu 10), but any release starting with 8.0.7 or later will work.<br />
* After the installation is complete, tar up clamav-0.95.1 on the new server:<br />
cd /opt/zimbra<br />
tar czf /tmp/clamav-0.98.4.tar.gz clamav-0.98.4 openssl-1.0.1j<br />
<br />
====Update Instructions====<br />
* Download the file from one of the previous links.<br />
* Untar the file.<br />
tar xzvf clamav-0.98.4.tar.gz<br />
* Stop ZCS services.<br />
zmcontrol stop<br />
* Change the symbolic link (run as root)<br />
rm clamav<br />
ln -s clamav-0.98.4 clamav<br />
ls -l clamav<br />
The output line will look similar to:<br />
lrwxrwxrwx 1 root root 25 Apr 9 15:39 clamav -> /opt/zimbra/clamav-0.98.4<br />
* Start services.<br />
zmcontrol start<br />
* If there are errors regarding libssl.so.1.0.0, make sure you've downloaded the latest version of the binaries. The latest version contains the openssl version used to build clamav, and is approximately 100MB and dated 10/25/2016. The previous version was about 91MB and dated 10/22/2016.<br />
<br />
===Confirm===<br />
You can confirm that the new version of ClamAV is running by checking /opt/zimbra/log/clamd.log. The most recent startup in the log should look similar to:<br />
Sat Oct 22 18:42:31 2016 -> +++ Started at Sat Oct 22 18:42:31 2016<br />
Sat Oct 22 18:42:31 2016 -> clamd daemon 0.98.4 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64)<br />
<br />
Test send-receive of mail.<br />
<br />
With ClamAV 0.98 in place, updates should continue uninterrupted after October 22, 2016, and your system will remain protected.<br />
<br />
This procedure was tested using ZCS 8.5.1 (and ZCS 8.0.9 for Ubuntu 10).<br />
<br />
{{Article Footer|ZCS 8.0.9 & 8.5.1|10/22/2016}}<br />
<br />
[[Category:Troubleshooting Anti-virus]]<br />
[[Category:ZCS 8.0]]</div>Publiskihttps://wiki.zimbra.com/index.php?title=ClamAV_-_Updating_clamd_for_releases_earlier_than_ZCS_8.0.6&diff=63104ClamAV - Updating clamd for releases earlier than ZCS 8.0.62016-10-25T06:02:48Z<p>Publiski: /* Other methods to obtain */</p>
<hr />
<div>{{BC|Certified}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=ClamAV - Updating clamd for releases earlier than ZCS 8.0.6 =<br />
{{KB|{{ZC}}|{{ZCS 8.0}}|{{ZCS 7.0}}||}}<br />
<br />
For those using ZCS 8.0.6 and prior, come 22 October 2016 anti-virus definitions will no longer update AND '''your ClamAV instance will stop working entirely'''.<br />
*EOL Source: http://blog.clamav.net/2016/05/clamav-097-engine-end-of-life.html<br />
<br />
==Preventative methods==<br />
* Update ZCS to a newer version.<br />
* Update just the ClamAV component.<br />
<br />
==Workaround==<br />
Zimbra Collaboration is the open source leader in email and collaboration. That means your company can benefit from the manual upgrade of some third party packages and keep your email server up, running and secure, while planning your upgrade to the latest ZCS Release.<br />
===Disable the antivirus===<br />
You can follow a workaround by disabling antivirus.<br />
This workaround will let your Zimbra Collaboration platform run without antivirus. However, '''we don’t recommend it.'''<br />
====Turn off ClamAV from your Admin Console====<br />
Go to Server > Services 'as/av' tab > uncheck av. <br />
====Via CLI====<br />
Run the next commands as zimbra user (The minus sign is important, or you'll leave nothing but av running.):<br />
zmprov ms `zmhostname` -zimbraServiceEnabled antivirus<br />
zmamavisdctl reload<br />
<br />
===Manual ClamAV component upgrade===<br />
Zimbra includes ClamAV 0.98.4 as of ZCS 8.0.7+. The clamav-0.98.4 directory from an installed ZCS 8.0.7 or later installation can be copied directly to an earlier ZCS 8.0/7.2.x server. To upgrade ClamAV, perform the following steps:<br />
====Downloads====<br />
Use the clamav version our team has generated for your Zimbra environments:<br />
* Redhat 6.x: [https://files.zimbra.com/downloads/clamav/rhel6_64/clamav-0.98.4.tar.gz clamav-0.98.4.tar.gz] [https://files.zimbra.com/downloads/clamav/rhel6_64/clamav-0.98.4.tar.gz.md5 md5] [https://files.zimbra.com/downloads/clamav/rhel6_64/clamav-0.98.4.tar.gz.sha256 sha256]<br><br />
* CentOS 6.x: [https://files.zimbra.com/downloads/clamav/rhel6_64/clamav-0.98.4.tar.gz clamav-0.98.4.tar.gz] [https://files.zimbra.com/downloads/clamav/rhel6_64/clamav-0.98.4.tar.gz.md5 md5] [https://files.zimbra.com/downloads/clamav/rhel6_64/clamav-0.98.4.tar.gz.sha256 sha256]<br> <br />
* SLES 11 64-bit: [https://files.zimbra.com/downloads/clamav/sles11_64/clamav-0.98.4.tar.gz clamav-0.98.4.tar.gz] [https://files.zimbra.com/downloads/clamav/sles11_64/clamav-0.98.4.tar.gz.md5 md5] [https://files.zimbra.com/downloads/clamav/sles11_64/clamav-0.98.4.tar.gz.sha256 sha256]<br><br />
* Ubuntu 10.04 64-bit: [https://files.zimbra.com/downloads/clamav/ubuntu10_64/clamav-0.98.4.tar.gz clamav-0.98.4.tar.gz] [https://files.zimbra.com/downloads/clamav/ubuntu10_64/clamav-0.98.4.tar.gz.md5 md5] [https://files.zimbra.com/downloads/clamav/ubuntu10_64/clamav-0.98.4.tar.gz.sha256 sha256]<br><br />
* Ubuntu 12.06 64-bit: [https://files.zimbra.com/downloads/clamav/ubuntu12_64/clamav-0.98.4.tar.gz clamav-0.98.4.tar.gz] [https://files.zimbra.com/downloads/clamav/ubuntu12_64/clamav-0.98.4.tar.gz.md5 md5] [https://files.zimbra.com/downloads/clamav/ubuntu12_64/clamav-0.98.4.tar.gz.sha256 sha256]<br><br />
<br />
=====Other methods to obtain=====<br />
* Install a new server with a later release of ZCS or use the above links. The Free Open-Source release of ZCS is available at http://www.zimbra.com/downloads/os-downloads.html. This document was tested with 8.5.1 (8.0.9 for Ubuntu 10), but any release starting with 8.0.7 or later will work.<br />
* After the installation is complete, tar up clamav-0.95.1 on the new server:<br />
cd /opt/zimbra<br />
tar czf /tmp/clamav-0.98.4.tar.gz clamav-0.98.4 openssl-1.0.1j<br />
<br />
====Update Instructions====<br />
* Download the file from one of the previous links.<br />
* Untar the file.<br />
tar xzvf clamav-0.98.4.tar.gz<br />
* Stop ZCS services.<br />
zmcontrol stop<br />
* Change the symbolic link (run as root)<br />
rm clamav<br />
ln -s clamav-0.98.4 clamav<br />
ls -l clamav<br />
The output line will look similar to:<br />
lrwxrwxrwx 1 root root 25 Apr 9 15:39 clamav -> /opt/zimbra/clamav-0.98.4<br />
* Start services.<br />
zmcontrol start<br />
* If there are errors regarding libssl.so.1.0.0, create a symbolic link to the file. Run the following as root:<br />
cd /opt/zimbra/clamav/lib<br />
ln -s ../../openssl-1.0.1e/lib/libssl.so.1.0.0 libssl.so.1.0.0<br />
ln -s ../../openssl-1.0.1e/lib/libcrypto.so.1.0.0 libcrypto.so.1.0.0<br />
su - zimbra<br />
zmantivirusctl restart<br />
<br />
===Confirm===<br />
You can confirm that the new version of ClamAV is running by checking /opt/zimbra/log/clamd.log. The most recent startup in the log should look similar to:<br />
Sat Oct 22 18:42:31 2016 -> +++ Started at Sat Oct 22 18:42:31 2016<br />
Sat Oct 22 18:42:31 2016 -> clamd daemon 0.98.4 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64)<br />
<br />
Test send-receive of mail.<br />
<br />
With ClamAV 0.98 in place, updates should continue uninterrupted after October 22, 2016, and your system will remain protected.<br />
<br />
This procedure was tested using ZCS 8.5.1 (and ZCS 8.0.9 for Ubuntu 10).<br />
<br />
{{Article Footer|ZCS 8.0.9 & 8.5.1|10/22/2016}}<br />
<br />
[[Category:Troubleshooting Anti-virus]]<br />
[[Category:ZCS 8.0]]</div>Publiskihttps://wiki.zimbra.com/index.php?title=ClamAV_-_Updating_clamd_for_releases_earlier_than_ZCS_8.0.6&diff=63067ClamAV - Updating clamd for releases earlier than ZCS 8.0.62016-10-22T22:46:20Z<p>Publiski: Created page with "{{Archive}}{{Article Infobox|{{admin}}||{{ZCS 8.0}}|}}For those using ZCS 8.0.6 and prior, come 22 October 2016 anti-virus definitions will no longer update AND '''your ClamAV..."</p>
<hr />
<div>{{Archive}}{{Article Infobox|{{admin}}||{{ZCS 8.0}}|}}For those using ZCS 8.0.6 and prior, come 22 October 2016 anti-virus definitions will no longer update AND '''your ClamAV instance will stop working entirely'''.<br />
<br />
EOL Source: http://blog.clamav.net/2016/05/clamav-097-engine-end-of-life.html<br />
<br />
==Preventative methods==<br />
-Update ZCS to a newer version.<br />
<br />
-Update just the ClamAV component.<br />
<br />
==Past EOL ?==<br />
<br />
-Turn off ClamAV from your admin console > server > services 'as/av' tab > uncheck av. Via CLI it's zmprov ms `zmhostname` -zimbraServiceEnabled Antivirus. (The minus sign is important, or you'll leave nothing but av running.) Then zmamavisdctl reload. (This may leave you more vulnerable of course.)<br />
<br />
-Update just the ClamAV component.<br />
<br />
==Manual ClamAV component upgrade:==<br />
<br />
Zimbra includes ClamAV 0.98.4 as of ZCS 8.0.7+. The clamav-0.95.1 directory from an installed ZCS 8.0.7 or later installation can be copied directly to an earlier ZCS 8.0/7.2.x server. To upgrade ClamAV, perform the following steps:<br />
<br />
===Downloads===<br />
Redhat 6.x: [https://files.zimbra.com/downloads/clamav/rhel6_64/clamav-0.98.4.tar.gz clamav-0.98.4.tar.gz] [https://files.zimbra.com/downloads/clamav/rhel6_64/clamav-0.98.4.tar.gz.md5 md5] [https://files.zimbra.com/downloads/clamav/rhel6_64/clamav-0.98.4.tar.gz.sha256 sha256]<br><br />
<br />
CentOS 6.x: [https://files.zimbra.com/downloads/clamav/rhel6_64/clamav-0.98.4.tar.gz clamav-0.98.4.tar.gz] [https://files.zimbra.com/downloads/clamav/rhel6_64/clamav-0.98.4.tar.gz.md5 md5] [https://files.zimbra.com/downloads/clamav/rhel6_64/clamav-0.98.4.tar.gz.sha256 sha256]<br> <br />
<br />
SLES 11 64-bit: [https://files.zimbra.com/downloads/clamav/sles11_64/clamav-0.98.4.tar.gz clamav-0.98.4.tar.gz] [https://files.zimbra.com/downloads/clamav/sles11_64/clamav-0.98.4.tar.gz.md5 md5] [https://files.zimbra.com/downloads/clamav/sles11_64/clamav-0.98.4.tar.gz.sha256 sha256]<br><br />
<br />
Ubuntu 10.04 64-bit: [https://files.zimbra.com/downloads/clamav/ubuntu10_64/clamav-0.98.4.tar.gz clamav-0.98.4.tar.gz] [https://files.zimbra.com/downloads/clamav/ubuntu10_64/clamav-0.98.4.tar.gz.md5 md5] [https://files.zimbra.com/downloads/clamav/ubuntu10_64/clamav-0.98.4.tar.gz.sha256 sha256]<br><br />
<br />
Ubuntu 12.06 64-bit: [https://files.zimbra.com/downloads/clamav/ubuntu12_64/clamav-0.98.4.tar.gz clamav-0.98.4.tar.gz] [https://files.zimbra.com/downloads/clamav/ubuntu12_64/clamav-0.98.4.tar.gz.md5 md5] [https://files.zimbra.com/downloads/clamav/ubuntu12_64/clamav-0.98.4.tar.gz.sha256 sha256]<br><br />
<br />
===Other methods to obtain===<br />
1. Install a new server with a later release of ZCS or use the above links. The Free Open-Source release of ZCS is available at http://www.zimbra.com/downloads/os-downloads.html. This document was tested with 8.5.1 (8.0.9 for Ubuntu 10), but any release starting with 8.0.7 or later will work.<br />
2. After the installation is complete, tar up clamav-0.95.1 on the new server:<br />
cd /opt/zimbra<br />
tar cf /tmp/clamav-0.98.4.tar clamav-0.98.4<br />
<br />
===The Actual Update Instructions===<br />
3. Copy this tar file to your existing ZCS server.<br />
cd /opt/zimbra<br />
scp ''user''@''server'':/tmp/clamav-0.98.4.tgz.<br />
4. Untar the file.<br />
tar xzf clamav-0.98.4.tgz<br />
5. Stop ZCS services.<br />
zmcontrol stop<br />
6. Change the symbolic link<br />
rm clamav<br />
ln -s clamav-0.98.4 clamav<br />
ls -l clamav<br />
The output line will look similar to:<br />
lrwxrwxrwx 1 root root 25 Apr 9 15:39 clamav -> /opt/zimbra/clamav-0.98.4<br />
7. Start services.<br />
zmcontrol start<br />
<br />
===Confirm===<br />
You can confirm that the new version of ClamAV is running by checking /opt/zimbra/log/clamd.log. The most recent startup in the log should look similar to:<br />
Sat Oct 22 18:42:31 2016 -> +++ Started at Sat Oct 22 18:42:31 2016<br />
Sat Oct 22 18:42:31 2016 -> clamd daemon 0.98.4 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64)<br />
<br />
Test send-recieve of mail.<br />
<br />
With ClamAV 0.98 in place, updates should continue uninterrupted after October 22, 2016, and your system will remain protected.<br />
<br />
This procedure was tested using ZCS 8.5.1 (and ZCS 8.0.9 for Ubuntu 10).<br />
<br />
<br />
{{Article Footer|ZCS 8.0.9 & 8.5.1|10/22/2016}}<br />
<br />
[[Category:Troubleshooting Anti-virus]]<br />
[[Category:ZCS 8.0]]</div>Publiskihttps://wiki.zimbra.com/index.php?title=SOAP_API_Reference_Manual&diff=62546SOAP API Reference Manual2016-07-21T19:58:28Z<p>Publiski: /* ZCS 8.7.0 */</p>
<hr />
<div>{{BC|Certified}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=SOAP API Reference Material beginning with Zimbra Collaboration=<br />
{{KB|{{ZC}}|{{ZCS 8.7}}|{{ZCS 8.6}}|{{ZCS 8.0}}|}}<br />
{{WIP}}The following links are to the online Zimbra SOAP API reference materials, beginning with Zimbra Collaboration Server 8.0. Changes made for future releases will be added as change log directories to this page.<br />
<br />
== ZCS 8.7.0 ==<br />
<br />
'''SOAP API''': [https://files.zimbra.com/docs/soap_api/8.7.0/api-reference/index.html HTML] | [https://files.zimbra.com/docs/soap_api/8.7.0/soapapi-zimbra-doc.zip ZIP]<br />
<br />
'''Change Log''': [https://files.zimbra.com/docs/soap_api/8.7.0/api-changelog/index.html HTML] | [https://files.zimbra.com/docs/soap_api/8.7.0/soapapi-changelog.zip ZIP]<br />
<br />
== ZCS 8.6.0 ==<br />
<br />
'''SOAP API''': [https://files.zimbra.com/docs/soap_api/8.6.0/api-reference/index.html HTML] | [https://files.zimbra.com/docs/soap_api/8.6.0/soapapi-zimbra-doc860.zip ZIP]<br />
<br />
'''Change Log''': [https://files.zimbra.com/docs/soap_api/8.6.0/api-changelog/index.html HTML] | [https://files.zimbra.com/docs/soap_api/8.6.0/soapapi-changelog860.zip ZIP]<br />
<br />
== ZCS 8.5.1 ==<br />
<br />
'''SOAP API''': [https://files.zimbra.com/docs/soap_api/8.5.1/api-reference/index.html HTML] | [https://files.zimbra.com/docs/soap_api/8.5.1/soapapi-zimbra-doc851.zip ZIP]<br />
<br />
'''Change Log''': [https://files.zimbra.com/docs/soap_api/8.5.1/api-changelog/index.html HTML] | [https://files.zimbra.com/docs/soap_api/8.5.1/soapapi-changelog851.zip ZIP]<br />
<br />
== ZCS 8.5.0 ==<br />
<br />
'''SOAP API''': [https://files.zimbra.com/docs/soap_api/8.5.0/api-reference/index.html HTML] | [https://files.zimbra.com/docs/soap_api/8.5.0/soapapi-zimbra-doc-850.zip ZIP]<br />
<br />
'''Change Log''': [https://files.zimbra.com/docs/soap_api/8.5.0/api-changelog/index.html HTML] | [https://files.zimbra.com/docs/soap_api/8.5.0/soapapi-changelog-850.zip ZIP]<br />
<br />
== ZCS 8.0.9 ==<br />
<br />
'''SOAP API''': [https://files.zimbra.com/docs/soap_api/8.0.9/api-reference/index.html HTML] | [https://files.zimbra.com/docs/soap_api/8.0.9/soapapi-zimbra-doc809.zip ZIP]<br />
<br />
'''Change Log''': [https://files.zimbra.com/docs/soap_api/8.0.9/api-changelog/index.html HTML] | [https://files.zimbra.com/docs/soap_api/8.0.9/soapapi-changelog809.zip ZIP]<br />
<br />
== ZCS 8.0.7 ==<br />
<br />
'''SOAP API''': [https://files.zimbra.com/docs/soap_api/8.0.7/soap-docs-807/api-reference/index.html HTML] | [https://files.zimbra.com/docs/soap_api/8.0.7/soapapi-zimbra-doc-807.zip ZIP]<br />
<br />
'''Change Log''': [https://files.zimbra.com/docs/soap_api/8.0.7/soap-docs-807/api-changelog/index.html HTML] | [https://files.zimbra.com/docs/soap_api/8.0.7/soapapi-changelog-807.zip ZIP]<br />
<br />
== ZCS 8.0.6 ==<br />
<br />
'''SOAP API''': [https://files.zimbra.com/docs/soap_api/8.0.6/soap-docs-806/api-reference/index.html HTML] | [https://files.zimbra.com/docs/soap_api/8.0.6/soapapi-zimbra-doc-806.zip ZIP]<br />
<br />
'''Change Log''': [https://files.zimbra.com/docs/soap_api/8.0.6/soap-docs-806/api-changelog/index.html HTML] | [https://files.zimbra.com/docs/soap_api/8.0.6/soapapi-changelog-806.zip ZIP]<br />
<br />
== ZCS 8.0.5 ==<br />
<br />
'''SOAP API''': [https://files.zimbra.com/docs/soap_api/8.0.5/soap-docs-805/api-reference/index.html HTML] | [https://files.zimbra.com/docs/soap_api/8.0.5/soapapi-zimbra-doc-805.zip ZIP]<br />
<br />
'''Change Log''': [https://files.zimbra.com/docs/soap_api/8.0.5/soap-docs-805/api-changelog/index.html HTML] | [https://files.zimbra.com/docs/soap_api/8.0.5/soapapi-changelog-805.zip ZIP]<br />
<br />
== ZCS 8.0.4 ==<br />
<br />
'''SOAP API''': [https://files.zimbra.com/docs/soap_api/8.0.4/soap-docs-804/api-reference/index.html HTML] | [https://files.zimbra.com/docs/soap_api/8.0.4/soapapi-zimbra-doc-804.zip ZIP]<br />
<br />
'''Change Log''': [https://files.zimbra.com/docs/soap_api/8.0.4/soap-docs-804/api-changelog/index.html HTML] | [https://files.zimbra.com/docs/soap_api/8.0.4/soapapi-changelog-804.zip ZIP]<br />
<br />
== ZCS 8.0.2 ==<br />
<br />
'''SOAP API''': [https://files.zimbra.com/docs/soap_api/8.0.2/soapapi-zimbra-doc/api-reference/index.html HTML] | [https://files.zimbra.com/docs/soap_api/8.0.2/soapapi-zimbra-doc-802.zip ZIP]<br />
<br />
== ZCS 8.0.0 ==<br />
<br />
'''SOAP API''': [https://files.zimbra.com/docs/soap_api/8.0/soapapi-zimbra-doc/api-reference/index.html HTML] | [https://files.zimbra.com/docs/soap_api/8.0/soapapi-zimbra-doc-80.zip ZIP]<br />
<br />
<br />
{{Article Footer|Zimbra Collaboration Server 8.0|4/2014}}<br />
<br />
[[Category:ZCS 8.6]]<br />
[[Category:ZCS 8.5]]<br />
[[Category:ZCS 8.0]]<br />
[[Category:SOAP]]</div>Publiskihttps://wiki.zimbra.com/index.php?title=Zimbra_Two-factor_authentication&diff=62346Zimbra Two-factor authentication2016-06-23T15:41:48Z<p>Publiski: </p>
<hr />
<div>{{BC|Community Sandbox}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=Zimbra Two-factor authentication=<br />
{{KB|{{ZCS 8.7}}||}}<br />
{{WIP}}<br />
<br />
Coming with Zimbra Collaboration 8.7 (only in Network Edition) is an exciting new feature: two-factor authentication (also known as 2FA). Two-factor authentication is a technology that provides identification of users with the combination of two different components. These components may be something that the user knows (like a password, UserID, etc) and something that the user possesses (a good example can be a smartphone, or USB-key, etc.)<br />
<br />
[[File:Zcs87-2fa-diagram.png]]<br />
<br />
==How it works==<br />
The use of two-factor authentication to prove your users’ identity is based on the premise that an unauthorized actor is unlikely to be able to supply both factors required for access. If, in an authentication attempt, at least one of the components is missing or incorrect, the user’s identity is not established with sufficient certainty and access to the user Zimbra Mailbox being protected by two-factor authentication remains blocked.<br />
<br />
[https://en.wikipedia.org/wiki/Two-factor_authentication (source: Wikipedia)]<br />
<br />
==How to enable it==<br />
=== Admin Console===<br />
The two-factor authentication feature must be enabled in the Admin Console, and it can be enabled at User or Class-of-service level. This allows precise control over the users Security. Therefore, you can enable this feature just for the most critical Mailboxes in the environment, to all users, etc.<br />
<br />
To enable it in the Admin Console: '''Home > Configure > Class of service > yourCOSname > Advanced > Two Factor Authentication'''<br />
<br />
Use the check-boxes to:<br />
* Enable two-factor authentication: enable or disable the two-factor authentication feature<br />
* Require two-step authentication: all users will need to configure the 2FA<br />
* Number of one-time codes to generate (per each user): more information here<br />
* Enable application passcodes: for legacy applications that don’t support 2FA. You can generate exceptions codes for them.<br />
<br />
[[File:Zcs87-2fa-001.png]]<br />
<br />
===How to enable two-factor authentication feature (User Web Client)===<br />
Once the Admin has been enabled and configured the 2FA, users will see a new option under '''Preferences > Accounts''', called '''Two Factor Authentication'''<br />
<br />
[[File:Zcs87-2fa-002.png]]<br />
<br />
If the user clicks on the '''Setup two-step authentication link''', the configuration process will begin.<br />
<br />
The first step shows a brief description about two-step authentication. The user must click on Begin Setup.<br />
<br />
[[File:Zcs87-2fa-003.png]]<br />
<br />
Next step will be introduce the user current password, if you remember the theory of 2FA, this will be “the component the user knows”. Once the user wrote the password, click on Next.<br />
<br />
[[File:Zcs87-2fa-004.png]]<br />
<br />
The next step retrieves the other component the user must have, in this case an app in the smartphone. The Two Factor authentication wizard will show a Wiki link with the OTP Apps Zimbra recommends to use.<br />
<br />
[[File:Zcs87-2fa-005.png]]<br />
<br />
Once the user has installed the App, the 2FA wizard will show a unique key that the user must enter in the Smartphone OTP App.<br />
<br />
[[File:Zcs87-2fa-006.png]]<br />
<br />
===How to Install and Configure an OTP smartphone app===<br />
In this example, I will use Google authenticator, but please visit our Wiki where you can find other options. In the App Store or Play Store, search by Google authenticator, then click '''Install'''.<br />
<br />
[[File:Zcs87-2fa-010.png|250px]]<br />
<br />
Once the app is installed, open it, and click '''Begin Setup'''.<br />
<br />
[[File:Zcs87-2fa-011.png|250px]]<br />
<br />
The app will ask if you want to configure a Manual entry or Scan a barcode. Zimbra Collaboration 8.7 supports only manual entry for now. However, [https://bugzilla.zimbra.com/show_bug.cgi?id=99511 keep in mind the next Bug] where it is being discussed to add the option to support barcodes.<br />
<br />
[[File:Zcs87-2fa-012.png|250px]]<br />
<br />
To configure the App, the users must add an email address and the unique Key from the Zimbra Web Client.<br />
<br />
[[File:Zcs87-2fa-013.png|250px]]<br />
<br />
All done! Now the app is configured and will show a 6-digit code that changes after 15 seconds.<br />
<br />
[[File:Zcs87-2fa-014.png|250px]]<br />
<br />
====Finishing the configuration in the Web Client====<br />
Once the user has the App configured and showing the 6 digit code, the user can enter the Code in the wizard window and click Next.<br />
<br />
[[File:Zcs87-2fa-007.png]]<br />
<br />
The two-step authentication feature is now enabled, and the user will be prompted for a code in each new Browser, smartphone, computer, or app where he or she tries to access the account.<br />
<br />
[[File:Zcs87-2fa-008.png]]<br />
<br />
In the users’ '''Preferences > Accounts > Account Security''' (if the Admin has enabled these options under the COS), the user will see more options like the one-time codes, Trusted devices, and Applications.<br />
as<br />
<br />
[[File:Zcs87-2fa-009.png]]<br />
<br />
==Testing Zimbra Two-factor authentication==<br />
===Testing a new Web Browser session in a new Computer===<br />
If the user now goes to another Web Browser, computer, smartphone, or if he or she tries to configure Zimbra Desktop, the user will successfully pass the two-factory authentication. For example on the Web Client:<br />
One-time Codes<br />
<br />
[[File:Zcs87-2fa-015.png]]<br />
<br />
With the two-factor authentication enabled, there may be a situation when the smartphone doesn’t have battery to answer the code challenge, or the device has been lost, etc. For cases like this, Zimbra introduces the One-time codes functionality. This function allow users to generate multiple codes to use in case of emergency. The total number of one-time codes can be configured by the Admin.<br />
<br />
The user can click on the One-time codes View option to see the codes. The user must keep the codes secure (written somewhere, in another device, etc.).<br />
<br />
[[File:Zcs87-2fa-016.png]]<br />
<br />
===Testing Zimbra Desktop with 2FA===<br />
* Pending<br />
===Testing Zimbra Connector for Outlook with 2FA===<br />
* Pending<br />
==Additonal Content==<br />
* <br />
==Identified Support Issues==<br />
* No Support issues reported yet.<br />
<br />
{{Article Footer|Zimbra Collaboration Suite 8.7|02/03/2016}}<br />
{{NeedSME|SME1|SME2|Copyeditor}}<br />
[[Category:ZCS 8.7]]</div>Publiski