Wiki source code of Zimbra Collaboration Server
Last modified by Sebastian Marsching on 2022/05/29 13:59
Hide last authors
| author | version | line-number | content |
|---|---|---|---|
 |
1.1 | 1 | {{toc/}} |
| 2 | |||
| 3 | # Using MailStore Archiving with Zimbra | ||
| 4 | |||
| 5 | This is a short description of how I configure [Zimbra](http://www.zimbra.com/) to work with the [MailStore](http://www.mailstore.com/) archiving software. | ||
| 6 | |||
| 7 | Changes in configuration file `/opt/zimbra/conf/amavisd.conf.in`: | ||
| 8 | |||
| 9 | ```diff | ||
| 10 | --- amavisd.conf.in.zimbra-dist 2011-06-03 20:22:33.856452812 +0200 | ||
| 11 | +++ amavisd.conf.in 2011-06-03 20:22:45.686544874 +0200 | ||
| 12 | @@ -156,6 +156,10 @@ | ||
| 13 | # $forward_method = 'smtp:[127.0.0.1]:10025'; # set to undef with milter! | ||
| 14 | %%uncomment SERVICE:archiving%%$archive_quarantine_method = 'smtp:[127.0.0.1]:10025'; | ||
| 15 | |||
| 16 | +# Enable archiving to fixed e-mail address | ||
| 17 | +$archive_quarantine_method = 'smtp:[127.0.0.1]:10025'; | ||
| 18 | +@archive_quarantine_to_maps = ('my-archiving-address@example.com'); | ||
| 19 | + | ||
| 20 | %%uncomment VAR:zimbraAmavisQuarantineAccount%%$final_virus_destiny = D_DISCARD; | ||
| 21 | $final_banned_destiny = D_BOUNCE; | ||
| 22 | $final_spam_destiny = D_DISCARD; | ||
| 23 | ``` | ||
| 24 | |||
| |
3.1 | 25 | This should send every e-mail passed through Zimbra to the address `my-archiving-address@example.com`. This is the POP3 or IMAP mailbox that MailStore uses to receive all e-mails. Amavis will take care of writing headers that help MailStore identify to which e-mail address the e-mail actually belongs, so that it can be archived in the right MailStore account. |
| |
1.1 | 26 | |
| 27 | I have been using this configuration with ZCS 7.1, 7.2 and 8.6. For other versions, the configuration file and thus the changes might look different. | ||
| 28 | |||
| 29 | # Make Zimbra only accept mail for existing accounts | ||
| 30 | |||
| 31 | By default, Zimbra accepts e-mails for addresses which are not valid and later sends a bounce mail. Unfortunately this can cause SPAM back-scatter and thus should be avoided (also see my [blog article](http://sebastian.marsching.com/blog/archives/97-Fighting-SPAM-Bounces-with-Exim-Part-I.html)). | ||
| 32 | |||
| 33 | In Zimbra 8.6 it is very simple to change this behavior: | ||
| 34 | |||
| 35 | ```bash | ||
| 36 | zmprov mcf +zimbraMtaRestriction reject_unverified_recipient | ||
| 37 | ``` | ||
| 38 | |||
| 39 | ## Effect on Hosts Listed in zimbraMtaMyNetworks | ||
| 40 | |||
| 41 | The change described above will have no effect on hosts listed in `zimbraMtaMyNetworks`. Therefore, if you have mail-server acting as a front-end to the Zimbra server, you should not list it in `zimbraMtaMyNetworks`. `zimbraMtaMyNetworks` should only contain the Zimbra server itself (and the loopback address). | ||
| 42 | |||
| |
3.1 | 43 | However, for OpenDKIM and SpamAssassin, you also want to trust your other mail servers. You can get this effect by editing the configuration files and adding the appropriate IP addresses there: |
| |
1.1 | 44 | |
| 45 | `/opt/zimbra/conf/opendkim-localnets.conf.in` (Zimbra 8 only): | ||
| |
3.1 | 46 | |
| |
2.1 | 47 | ``` |
| 48 | %%zimbraMtaMyNetworksPerLine%% | ||
| 49 | 192.0.2.1/32 | ||
| 50 | [2001:db8::1]/128 | ||
| 51 | ``` | ||
| |
3.1 | 52 | |
| 53 | `/opt/zimbra/conf/salocal.cf.in`: | ||
| 54 | |||
| |
2.1 | 55 | ``` |
| 56 | %%uncomment VAR:zimbraMtaMyNetworks%%trusted_networks %%zimbraMtaMyNetworks%% 192.0.2.1/32 [2001:db8::1]/128 | ||
| 57 | ``` | ||
| |
1.1 | 58 | |
| 59 | In recent Zimbra versions (ZCS 8.5 and newer) it might be more elegant to add your own `trusted_networks` line to `/opt/zimbra/data/spamassassin/localrules/sauser.cf`. | ||
| 60 | |||
| |
3.1 | 61 | **Important note:** Earlier versions of this tutorial suggested also adding the hosts to the `@mynetworks` list in `amavisd.conf.in`. However, this is not a good idea because it will cause SpamAssassin to treat all e-mail as "submitted" by an authenticated client and thus it will also treat all hosts as trusted, even if it would not otherwise (as explained on the [SpamAssassin mailing list](http://mail-archives.apache.org/mod_mbox/spamassassin-users/201604.mbox/%3Cxn0k4sewlxfk5pi005%40news.gmane.org%3E)). For this reason, `zimbraMtaMyNetworks` should only contain the Zimbra server itself and the `@mynetworks` option in the Amavis configuration should not be changed. |
| |
1.1 | 62 | |
| 63 | # Mailbox Selected READ-ONLY Error in Thunderbird | ||
| 64 | |||
| 65 | Sometimes Thunderbird report the error "Mailbox selected READ-ONLY" when trying to move an e-mail from the inbox. The e-mail is copied to the target folder but not removed from the inbox. Besides the read flag will not be set correctly. | ||
| 66 | |||
| 67 | This problem seems to be related to the [Ehcache feature](http://www.zimbra.com/forums/administrators/58281-7-2-0-mailbox-selected-read-only-errors.html) in Zimbra. For me disable Ehcache solved the problem in Zimbra 7 and 8: | ||
| 68 | |||
| 69 | ```bash | ||
| 70 | zmlocalconfig -e imap_use_ehcache=false | ||
| 71 | ``` | ||
| 72 | |||
| 73 | # IPv6 and Zimbra 8 | ||
| 74 | |||
| 75 | There are two potential problems when using Zimbra 8 on a IPv6-enabled host: The first problem concerns OpenLDAP and the second one concerns OpenDKIM. | ||
| 76 | |||
| 77 | ## Fixing the OpenLDAP Problem | ||
| 78 | |||
| 79 | Fixing the OpenLDAP problem is easy: Set the local configuration option `ldap_bind_url` to `ldap:///`: | ||
| 80 | |||
| 81 | ```bash | ||
| 82 | zmlocalconfig -e ldap_bind_url=ldap:/// | ||
| 83 | ``` | ||
| 84 | |||
| 85 | After this change you have to restart Zimbra. For details refer to the [article in my blog](http://sebastian.marsching.com/blog/archives/126-OpenLDAP-Server-not-listening-on-IPv6-Socket-in-Zimbra-8.html). | ||
| 86 | |||
| 87 | This change should survive minor Upgrades of Zimbra (e.g. from Zimbra 8.0.3 to Zimbra 8.0.5). | ||
| 88 | |||
| 89 | ## Fixing the OpenDKIM Problem | ||
| 90 | |||
| 91 | Fixing the OpenDKIM problem is a bit more tricky: You have to edit the file `/opt/zimbra/conf/opendkim.conf.in` and change the line | ||
| 92 | |||
| 93 | Socket %%zimbraInetMode%%:8465@[%%zimbraLocalBindAddress%%] | ||
| 94 | |||
| 95 | to | ||
| 96 | |||
| 97 | Socket inet:8465@[127.0.0.1] | ||
| 98 | |||
| 99 | After this change you have to restart Zimbra. For details refer to the [article in my blog](http://sebastian.marsching.com/blog/archives/124-OpenDKIM-bug-in-Zimbra-Collaboration-Server.html). | ||
| 100 | |||
| 101 | Unfortunately, this change is overwritten when updating Zimbra, therefore it has to be applied again after each update. | ||
| 102 | |||
| 103 | # Fixing the zmsaupdate cron-job | ||
| 104 | |||
| 105 | Some of versions of Zimbra (I noticed it in Zimbra 8.0.6) have a bug that causes the cron job for `zmsaupdate` to fail if `/bin/sh` is not pointing to a Bource Again Shell (Bash) (e.g. Ubuntu 12.04 LTS). The error message (send to the local `zimbra` user) looks like that: | ||
| 106 | |||
| 107 | /bin/sh: 28: /opt/zimbra/.bashrc: [[: not found | ||
| 108 | /bin/sh: 36: [: Linux: unexpected operator | ||
| 109 | |||
| 110 | The fix for this is simple: The command has to be wrapped in a call to Bash. This can be done by editing Zimbra's crontab (`crontab -u zimbra -e`) and changing the line | ||
| 111 | |||
| 112 | 45 0 * * * . /opt/zimbra/.bashrc; /opt/zimbra/libexec/zmsaupdate | ||
| 113 | |||
| 114 | to | ||
| 115 | |||
| 116 | 45 0 * * * /bin/bash -c ". /opt/zimbra/.bashrc; /opt/zimbra/libexec/zmsaupdate" | ||
| 117 | |||
| 118 | # SSL / TLS options | ||
| 119 | |||
| 120 | ## Disabling SSLv3 | ||
| 121 | |||
| 122 | The [article in the Zimbra Wiki](https://wiki.zimbra.com/wiki/How_to_disable_SSLv3) extensively describes how to disable SSLv3. Since Zimbra 8.6, the supported TLS protocol versions can be controlled through the `zimbraMailboxdSSLProtocols` and `zimbraReverseProxySSLProtocols` options. | ||
| 123 | |||
| 124 | For adjusting the list of supported ciphers you might want to refer to the following sites: | ||
| 125 | |||
| 126 | * [http://wiki.zimbra.com/wiki/Cipher_suites](http://wiki.zimbra.com/wiki/Cipher_suites) | ||
| 127 | * [http://wiki.zimbra.com/wiki/Postfix_PCI_Compliance_in_ZCS](http://wiki.zimbra.com/wiki/Postfix_PCI_Compliance_in_ZCS) | ||
| 128 | * [http://wiki.zimbra.com/wiki/Weak_Cipher_Suites_Appear_in_Security_Scans](http://wiki.zimbra.com/wiki/Weak_Cipher_Suites_Appear_in_Security_Scans) | ||
| 129 | |||
| 130 | ## TLS Ciphers | ||
| 131 | |||
| 132 | Inspired by the [BetterCrypto guide](https://bettercrypto.org/), I use the following settings (communication with other mail-servers always goes through another MTA, therefore I can be quite strict): | ||
| 133 | |||
| 134 | ```bash | ||
| 135 | zmprov mcf zimbraMtaSmtpdTlsCiphers high | ||
| 136 | zmprov mcf zimbraMtaSmtpdTlsMandatoryCiphers high | ||
| 137 | zmprov mcf zimbraMtaSmtpdTlsExcludeCiphers aNULL,eNULL,LOW,3DES,MD5,EXP,PSK,DSS,RC4,SEED,ECDSA,DES | ||
| 138 | zmprov mcf zimbraMtaSmtpdTlsProtocols \!SSLv2,\!SSLv3 | ||
| 139 | zmprov mcf zimbraReverseProxySSLCiphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 | ||
| 140 | zmprov mcf +zimbraReverseProxySSLProtocols TLSv1.3 | ||
| 141 | zmprov mcf -zimbraReverseProxySSLProtocols TLSv1 | ||
| 142 | zmprov mcf -zimbraReverseProxySSLProtocols TLSv1.1 | ||
| 143 | zmprov mcf +zimbraSSLExcludeCipherSuites SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA | ||
| 144 | zmprov mcf +zimbraSSLExcludeCipherSuites SSL_DHE_DSS_WITH_DES_CBC_SHA | ||
| 145 | zmprov mcf +zimbraSSLExcludeCipherSuites SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA | ||
| 146 | zmprov mcf +zimbraSSLExcludeCipherSuites SSL_DHE_RSA_WITH_DES_CBC_SHA | ||
| 147 | zmprov mcf +zimbraSSLExcludeCipherSuites SSL_RSA_EXPORT_WITH_DES40_CBC_SHA | ||
| 148 | zmprov mcf +zimbraSSLExcludeCipherSuites SSL_RSA_EXPORT_WITH_RC4_40_MD5 | ||
| 149 | zmprov mcf +zimbraSSLExcludeCipherSuites SSL_RSA_WITH_DES_CBC_SHA | ||
| 150 | zmprov mcf +zimbraSSLExcludeCipherSuites SSL_RSA_WITH_RC4_128_MD5 | ||
| 151 | zmprov mcf +zimbraSSLExcludeCipherSuites SSL_RSA_WITH_3DES_EDE_CBC_SHA | ||
| 152 | zmprov mcf +zimbraSSLExcludeCipherSuites SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA | ||
| 153 | zmprov mcf +zimbraSSLExcludeCipherSuites SSL_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA | ||
| 154 | zmprov mcf +zimbraSSLExcludeCipherSuites TLS_DHE_RSA_WITH_AES_128_CBC_SHA | ||
| 155 | zmprov mcf +zimbraSSLExcludeCipherSuites TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 | ||
| 156 | zmprov mcf +zimbraSSLExcludeCipherSuites TLS_DHE_RSA_WITH_AES_256_CBC_SHA | ||
| 157 | zmprov mcf +zimbraSSLExcludeCipherSuites TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 | ||
| 158 | ``` | ||
| 159 | |||
| 160 | A word regarding the ciphers and protocols that we configure for the reverse proxy: We disable TLS 1.0 and 1.1 because they are not considered secure any longer and most browsers have dropped support for them anyway. We enable **all** TLSv1.3 ciphers because they seem to be enabled anyway, even if we do not list them. We prefer 256 bit ciphers over 128 bit ciphers. A minimal modern list supporting both TLSv1.2 and TLSv1.3 would look like this: | ||
| 161 | |||
| 162 | TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305 | ||
| 163 | |||
| 164 | We include the CHACHA20 ciphers because some systems that do support them do not support AES256, and they should be better than AES128. | ||
| 165 | |||
| 166 | In addition to that list, we add the AES128-GCM ciphers because Android 5.0 and 6.0 apparently neither support AES256 nor CHACHA20. We add the CBC ciphers to the end of the list, because IE 11 on Windows 8.1 (and Windows Server 2012 R2) does not support GCM yet. The AES256-CBC variant would be sufficient for that, but also supporting AES128-CBC also gives us support for IE11 on Windows Phone 8.1, and it is probably not significantly more insecure than AES256-CBC. | ||
| 167 | |||
| 168 | It probably is a good idea to completely remove the AES-CBC ciphers when Windows 8.1 / Windows Server 2012 R2 drop out of support in 2023. | ||
| 169 | |||
| 170 | In addition to these changes, it makes sense to enable TLSv1.3 and disable TLSv1.0 and TLSv1.1 for mailboxd. This happens through `zmlocalconfig`. Run `zmlocalconfig mailboxd_java_options` to display the current options and edit the `https.protocols` and `jdk.tls.client.protocols` options. Then set the resulting string through `zmlocalconfig`. For example: | ||
| 171 | |||
| 172 | ```bash | ||
| 173 | zmlocalconfig -e mailboxd_java_options="-server -Dhttps.protocols=TLSv1.2,TLSv1.3 -Djdk.tls.client.protocols=TLSv1.2,TLSv1.3 -Djava.awt.headless=true -Dsun.net.inetaddr.ttl= -Dorg.apache.jasper.compiler.disablejsr199=true -XX:+UseG1GC -XX:SoftRefLRUPolicyMSPerMB=1 -XX:-OmitStackTraceInFastThrow -verbose:gc -Xlog:gc*=debug,safepoint=info:file=/opt/zimbra/log/gc.log:time:filecount=20,filesize=10m" | ||
| 174 | ``` | ||
| 175 | |||
| 176 | ## Strict-Transport-Security Header | ||
| 177 | |||
| 178 | It makes sense to add the Strict-Transport-Security header so that the web interface is never used through an unencrypted connection. I got the idea [here](http://blog.capitar.com/getting-a-better-zimbra-ssl-labs-rating/)). I use these settings with Zimbra 8.6. | ||
| 179 | |||
| 180 | Typically, the `add_header` option needs to be added to two files: | ||
| 181 | |||
| 182 | * `/opt/zimbra/conf/nginx/templates/nginx.conf.web.https.default.template` | ||
| 183 | * `/opt/zimbra/conf/nginx/templates/nginx.conf.web.https.template` | ||
| 184 | |||
| 185 | The option is added in the following form and add it right after the `ssl_verify_depth` option: | ||
| 186 | |||
| 187 | add_header Strict-Transport-Security max-age=15768000; | ||
| 188 | |||
| 189 | Since Zimbra 8.7 there is a simpler option for adding this header: | ||
| 190 | |||
| 191 | ```bash | ||
| 192 | zmprov mcf +zimbraResponseHeader "Strict-Transport-Security: max-age=15768000" | ||
| 193 | ``` | ||
| 194 | |||
| 195 | If you enable the Nginx proxy for the first time, do not forget to (re-)enable the redirect mode (unless you are using the pure https mode): | ||
| 196 | |||
| 197 | ```bash | ||
| 198 | zmprov ms <server> zimbraReverseProxyMailMode redirect | ||
| 199 | ``` | ||
| 200 | |||
| 201 | You also might have to configure the protocol and hostname used for generating URLs (otherwise, some generated URLs might use the http scheme): | ||
| 202 | |||
| 203 | ```bash | ||
| 204 | zmprov md <domain> zimbraPublicServiceHostname <server> | ||
| 205 | zmprov md <domain> zimbraPublicServiceProtocol https | ||
| 206 | ``` | ||
| 207 | |||
| 208 | ## Adjusting the DH key size | ||
| 209 | |||
| 210 | By default, Nginx only uses 1024 bit keys when using the TLS_DH_* ciphers (Diffie-Hellman key exchange). This is not considered enough any longer. In order to increase this size, the Diffie-Hellman parameters need to be configured explicitly. I am using the following settings with Zimbra 8.6. | ||
| 211 | |||
| 212 | First, the DH parameters need to be generated with OpenSSL: | ||
| 213 | |||
| 214 | ```bash | ||
| 215 | openssl dhparam -outform PEM -out /opt/zimbra/conf/dhparam2048.pem 2048 | ||
| 216 | ``` | ||
| 217 | |||
| 218 | Next, the `ssl_dhparam` option has to be added to the relevant sections of the Nginx configuration. I added it to the following configuration files, right before the `ssl_ecdh_curve` option: | ||
| 219 | |||
| 220 | * `/opt/zimbra/conf/nginx/templates/nginx.conf.mail.template` | ||
| 221 | * `/opt/zimbra/conf/nginx/templates/nginx.conf.web.admin.default.template` | ||
| 222 | * `/opt/zimbra/conf/nginx/templates/nginx.conf.web.admin.template` | ||
| 223 | * `/opt/zimbra/conf/nginx/templates/nginx.conf.web.https.default.template` | ||
| 224 | * `/opt/zimbra/conf/nginx/templates/nginx.conf.web.https.template` | ||
| 225 | * `/opt/zimbra/conf/nginx/templates/nginx.conf.web.sso.default.template` | ||
| 226 | * `/opt/zimbra/conf/nginx/templates/nginx.conf.web.sso.template` | ||
| 227 | |||
| 228 | The configuration line should look like this: | ||
| 229 | |||
| 230 | ssl_dhparam /opt/zimbra/conf/dhparam2048.pem; | ||
| 231 | |||
| 232 | Starting with Zimbra 8.7, Zimbra uses 2048 bit DH params by default and this manual intervention is not necessary any longer. | ||
| 233 | |||
| 234 | # Fixing the logrotate script | ||
| 235 | |||
| 236 | The logrotate script (`/etc/logrotate.d/zimbra`) for the Nginx log files has a small problem ([Bug 106800](https://bugzilla.zimbra.com/show_bug.cgi?id=106800)): It might happen, that the compression of the logfile starts before Nginx has stopped writing to the logfile. This might result in an e-mail with the following content being sent to the administrator: | ||
| 237 | |||
| 238 | /etc/cron.daily/logrotate: | ||
| 239 | gzip: stdin: file size changed while zipping | ||
| 240 | |||
| 241 | At the moment, I am testing the following workaround for this issue: I changed the logrotate script to wait for five seconds after sending SIGUSR1 to Nginx. This should allow Nginx to reopen the file: | ||
| 242 | |||
| 243 | postrotate | ||
| 244 | kill -USR1 `cat /opt/zimbra/log/nginx.pid 2> /dev/null` 2> /dev/null && sleep 5 || true | ||
| 245 | endscript | ||
| 246 | |||
| 247 | If this does not help, the `delaycompress` option should fix it for sure. | ||
| 248 | |||
| 249 | # Enabling SpamAssassin rule updates | ||
| 250 | |||
| |
3.1 | 251 | Since Zimbra 8, it might be necessary to explicitly enable SpamAssassin rule updates (see [this article](https://wiki.zimbra.com/wiki/Anti-spam_Strategies) in the Zimbra knowledge-base). You can do this through `zmlocalconfig`: |
| |
1.1 | 252 | |
| 253 | ```bash | ||
| 254 | zmlocalconfig -e antispam_enable_rule_updates=true | ||
| 255 | zmlocalconfig -e antispam_enable_restarts=true | ||
| 256 | zmlocalconfig -e antispam_enable_rule_compilation=true | ||
| 257 | ``` | ||
| 258 | |||
| 259 | The last line is only necessary if you want to compile rules (this should improve the scan performance). | ||
| 260 | |||
| 261 | # Adding Pyzor and Razor to SpamAssassin | ||
| 262 | |||
| 263 | This has been heavily inspired by [https://wiki.zimbra.com/wiki/Improving_Anti-spam_system](https://wiki.zimbra.com/wiki/Improving_Anti-spam_system) and [https://wiki.zimbra.com/wiki/Anti-spam_Strategies](https://wiki.zimbra.com/wiki/Anti-spam_Strategies), but it use a different path for the configuration files so that they do not get lost during a Zimbra upgrade. | ||
| 264 | |||
| 265 | ## Pyzor | ||
| 266 | |||
| 267 | Install the package (as root): | ||
| 268 | |||
| 269 | ```bash | ||
| 270 | aptitude install pyzor | ||
| 271 | ``` | ||
| 272 | |||
| 273 | Create a symbol link in the Zimbra directory (as root): | ||
| 274 | |||
| 275 | ```bash | ||
| 276 | ln -s data/pyzor /opt/zimbra/.pyzor | ||
| 277 | ``` | ||
| 278 | |||
| 279 | Run **all remaining actions** as the **zimbra** user (`su - zimbra`). | ||
| 280 | |||
| 281 | Create the configuration directory: | ||
| 282 | |||
| 283 | ```bash | ||
| 284 | mkdir /opt/zimbra/data/pyzor | ||
| 285 | ``` | ||
| 286 | |||
| 287 | Create a symbol link in the amavisd directory: | ||
| 288 | |||
| 289 | ```bash | ||
| 290 | ln -s ../pyzor /opt/zimbra/data/amavisd/.pyzor | ||
| 291 | ``` | ||
| 292 | |||
| |
3.1 | 293 | Optionally, increase the timeout for Pyzor by adding the `pyzor_timeout` option to the SpamAssassin configuration. For example: |
| |
1.1 | 294 | |
| 295 | pyzor_timeout 20 | ||
| 296 | |||
| 297 | In recent Zimbra versions, you can add this line to `/opt/zimbra/data/spamassassin/localrules/sauser.cf`. | ||
| 298 | |||
| 299 | ## Razor | ||
| 300 | |||
| 301 | Install the package (as root): | ||
| 302 | |||
| 303 | ```bash | ||
| 304 | aptitude install razor | ||
| 305 | ``` | ||
| 306 | |||
| 307 | Create a symbol link in the Zimbra directory (as root): | ||
| 308 | |||
| 309 | ```bash | ||
| 310 | ln -s data/razor /opt/zimbra/.razor | ||
| 311 | ``` | ||
| 312 | |||
| 313 | Run **all remaining actions** as the **zimbra** user (`su - zimbra`). | ||
| 314 | |||
| 315 | Create the configuration directory: | ||
| 316 | |||
| 317 | ```bash | ||
| 318 | mkdir /opt/zimbra/data/razor | ||
| 319 | ``` | ||
| 320 | |||
| 321 | Create a symbol link in the `amavisd` directory: | ||
| 322 | |||
| 323 | ```bash | ||
| 324 | ln -s ../razor /opt/zimbra/data/amavisd/.razor | ||
| 325 | ``` | ||
| 326 | |||
| 327 | Initialize the configuration: | ||
| 328 | |||
| 329 | ```bash | ||
| 330 | razor-admin -create | ||
| 331 | razor-admin -discover | ||
| 332 | razor-admin -register | ||
| 333 | ``` | ||
| 334 | |||
| 335 | # Using the ClamAV Unofficial Signatures | ||
| 336 | |||
| 337 | Adding more signatures to ClamAV can help in improving the detection rate for virus scans. The ClamAV Unofficial Signatures Updater is available from [GitHub](https://github.com/extremeshok/clamav-unofficial-sigs). In order to install the script, one should download the newest release in the `.tar.gz` format from the [releases page](https://github.com/extremeshok/clamav-unofficial-sigs/releases) (version 5.4.1 in this example) and unpack it in `/opt/zimbra`. One should then create a symbol-link from `clamav-unofficial-sigs` to the directory created when unpacking the archive and make the script executable, for example: | ||
| 338 | |||
| 339 | ```bash | ||
| 340 | ln -s clamav-unofficial-sigs-5.4.1 /opt/zimbra/clamav-unofficial-sigs | ||
| 341 | chmod a+x /opt/zimbra/clamav-unofficial-sigs/clamav-unofficial-sigs.sh | ||
| 342 | ``` | ||
| 343 | |||
| 344 | All remaining steps should be done as the `zimbra` user. | ||
| 345 | |||
| 346 | Create directories for the script’s configuration and data: | ||
| 347 | |||
| 348 | ```bash | ||
| 349 | mkdir /opt/zimbra/conf/clamav-unofficial-sigs | ||
| 350 | mkdir /opt/zimbra/data/clamav-unofficial-sigs | ||
| 351 | ``` | ||
| 352 | |||
| 353 | Copy the `master.conf` and example `user.conf` from the distribution to the configuration directory: | ||
| 354 | |||
| 355 | ```bash | ||
| 356 | cp /opt/zimbra/clamav-unofficial-sigs/config/master.conf /opt/zimbra/conf/clamav-unofficial-sigs | ||
| 357 | cp /opt/zimbra/clamav-unofficial-sigs/config/user.conf /opt/zimbra/conf/clamav-unofficial-sigs | ||
| 358 | ``` | ||
| 359 | |||
| 360 | Create a `/opt/zimbra/conf/clamav-unofficial-sigs/os.conf` file that contains OS-specific paths, etc. As these paths differ from the ones typically used for the operating system (Zimbra brings its own version of ClamAV), one cannot use one of the example files. The following file works with Zimbra 8.7 on Ubuntu 14.04 LTS and with the ClamAV Unofficial Signatures Updater 5.4.1, but changes might be needed when using a different version of Zimbra, a different operating system, or a differet version of the updater script. | ||
| 361 | |||
| 362 | ```bash | ||
| 363 | # This file contains os configuration settings for clamav-unofficial-sigs.sh | ||
| 364 | ################### | ||
| 365 | # This is property of eXtremeSHOK.com | ||
| 366 | # You are free to use, modify and distribute, however you may not remove this notice. | ||
| 367 | # Copyright (c) Adrian Jon Kriel :: admin@extremeshok.com | ||
| 368 | ################## | ||
| 369 | # | ||
| 370 | # Script updates can be found at: https://github.com/extremeshok/clamav-unofficial-sigs | ||
| 371 | # | ||
| 372 | # Originially based on: | ||
| 373 | # Script provide by Bill Landry (unofficialsigs@gmail.com). | ||
| 374 | # | ||
| 375 | # License: BSD (Berkeley Software Distribution) | ||
| 376 | # | ||
| 377 | ################## | ||
| 378 | # | ||
| 379 | # NOT COMPATIBLE WITH VERSION 3.XX / 4.XX CONFIG | ||
| 380 | # | ||
| 381 | ################################################################################ | ||
| 382 | # SEE MASTER.CONF FOR CONFIG EXPLAINATIONS | ||
| 383 | ################################################################################ | ||
| 384 | # Rename to os.conf to enable this file | ||
| 385 | ################################################################################ | ||
| 386 | |||
| 387 | # Zimbra | ||
| 388 | |||
| 389 | clam_user="zimbra" | ||
| 390 | clam_group="zimbra" | ||
| 391 | |||
| 392 | clam_dbs="/opt/zimbra/data/clamav/db" | ||
| 393 | |||
| 394 | clamd_pid="/opt/zimbra/log/clamd.pid" | ||
| 395 | |||
| 396 | clamd_restart_opt="/opt/zimbra/bin/zmclamdctl restart" | ||
| 397 | |||
| 398 | clamd_reload_opt="/opt/zimbra/common/bin/clamdscan --config-file=/opt/zimbra/conf/clamd.conf --reload" | ||
| 399 | |||
| 400 | clamscan_bin="/opt/zimbra/common/bin/clamscan" | ||
| 401 | |||
| 402 | #clamd_socket="/var/run/clamav/clamd.ctl" | ||
| 403 | |||
| 404 | work_dir="/opt/zimbra/data/clamav-unofficial-sigs" | ||
| 405 | log_file_path="/opt/zimbra/log" | ||
| 406 | |||
| 407 | # https://eXtremeSHOK.com ###################################################### | ||
| 408 | ``` | ||
| 409 | |||
| 410 | One also has to make some modifications to the `user.conf` file. As an absolute minimum, the line `user_configuration_complete="yes"` has to be added or the updater script will not work. I also chose to set the following options: | ||
| 411 | |||
| 412 | securiteinfo_enabled="no" # SecuriteInfo | ||
| 413 | malwarepatrol_enabled="no" # Malware Patrol | ||
| 414 | downloader_ignore_ssl="no" # do not ignore SSL (certifcate) errors when | ||
| 415 | # downloading files | ||
| 416 | |||
| 417 | Finally, one has to add the following line to the `crontab` file of the `zimbra` user (`crontab -u zimbra -e`): | ||
| 418 | |||
| 419 | # Update unofficial ClamAV signatures | ||
| 420 | 45 * * * * /bin/bash /opt/zimbra/clamav-unofficial-sigs/clamav-unofficial-sigs.sh -c /opt/zimbra/conf/clamav-unofficial-sigs >/dev/null | ||
| 421 | |||
| 422 | it is a good idea to once run this script manually in order to see whether everything is working (`/bin/bash /opt/zimbra/clamav-unofficial-sigs/clamav-unofficial-sigs.sh -c /opt/zimbra/conf/clamav-unofficial-sigs`). | ||
| 423 | |||
| 424 | After running the script, one can check whether ClamAV is actually using the signatures by running `clamscan --debug -d /opt/zimbra/data/clamav/db /dev/null 2>&1|grep loaded`. In addition to the regular ClamAV signatures, one should see the signatures added by the updater script (the exact list depends on the configuration). | ||
| 425 | |||
| 426 | # Use Zimbra for system mail | ||
| 427 | |||
| 428 | The paths are for Zimbra 8.7: | ||
| 429 | |||
| 430 | ```bash | ||
| 431 | update-alternatives \ | ||
| 432 | --install /usr/sbin/sendmail mta /opt/zimbra/common/sbin/sendmail 25 \ | ||
| 433 | --slave /usr/bin/mailq mta-mailq /opt/zimbra/common/sbin/mailq \ | ||
| 434 | --slave /usr/bin/newaliases mta-newaliases /opt/zimbra/common/sbin/newaliases \ | ||
| 435 | --slave /usr/share/man/man1/mailq.1.gz mta-mailqman /opt/zimbra/common/share/man/man1/mailq.1 \ | ||
| 436 | --slave /usr/share/man/man1/newaliases.1.gz mta-newaliasesman /opt/zimbra/common/share/man/man1/newaliases.1 \ | ||
| 437 | --slave /usr/share/man/man8/sendmail.8.gz mta-sendmailman /opt/zimbra/common/share/man/man1/sendmail.1 \ | ||
| 438 | --slave /usr/share/man/man5/aliases.5.gz mta-aliasesman /opt/zimbra/common/share/man/man5/aliases.5 | ||
| 439 | ``` | ||
| 440 | |||
| 441 | # Synchronizing contacts with the macOS Contacts app (CardDAV) | ||
| 442 | |||
| 443 | Contacts that are stored in Zimbra can be synchronized with the macOS Contacts app through the CardDAV protocol. However, there seems to be one severe limitation at least up to macOS 10.12.5 (Sierra). Only one address book can be synchronized. If there is more than one address book, the “first” one is selected. In this case, “first” seems to be decided based on the lexical order. In my case, I had an extra address book starting with the letter “A” and this one would be chosen instead of the standard “Contacts” address book. I could fix this by renaming the extra address book. | ||
| 444 | |||
| 445 | # Remove submitting clients IP address from headers | ||
| 446 | |||
| 447 | By default, the IP address of the client that submitted an e-mail is visible through the `Received` header added by Postfix. This might not be desirable for privacy reasons. I got the basic idea from [here](https://www.x4b.net/kb/MailServerClientProtection), but I had to adapt it to make it work with Zimbra 8.8. | ||
| 448 | |||
| 449 | We add the following lines to `/opt/zimbra/conf/postfix_header_checks.in`: | ||
| 450 | |||
| 451 | /^Received:.*with ESMTPSA/ | ||
| 452 | IGNORE | ||
| 453 | /^X-Originating-IP:/ | ||
| 454 | IGNORE | ||
| 455 | |||
| 456 | Please note that there is a tab (not spaces) in front of `IGNORE`. | ||
| 457 | |||
| 458 | Unfortunately, Zimbra does not use the header checks file by default and manually setting the `header_checks` option in Postfix's `main.cf` does not work either, because it is overwritten when Postfix is started. There are two ways to fix this. One can either set the `zimbraMtaBlockedExtensionWarnRecipient` configuration option to `FALSE` like suggested [here](https://wiki.zimbra.com/wiki/King0770-Notes-Header-Checks): | ||
| 459 | |||
| 460 | ```bash | ||
| 461 | zmprov mcf zimbraMtaBlockedExtensionWarnRecipient FALSE | ||
| 462 | ``` | ||
| 463 | |||
| 464 | The other solution is changing the configuration of `zmconfigd` by removing the following lines from `/opt/zimbra/conf/zmconfigd.cf`: | ||
| 465 | |||
| 466 | if VAR zimbraMtaBlockedExtensionWarnRecipient | ||
| 467 | POSTCONF header_checks | ||
| 468 | fi | ||
| 469 | |||
| 470 | Most likely, you also want to set the `zimbraSmtpSendAddOriginatingIP` to `FALSE`: | ||
| 471 | |||
| 472 | ```bash | ||
| 473 | zmprov mcf zimbraSmtpSendAddOriginatingIP FALSE | ||
| 474 | ``` |