Zimbra Collaboration Server

# Using MailStore Archiving with Zimbra

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

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](https://sebastian.marsching.com/wiki/MailStore) uses to receive all e-mails. Amavis will take care of writing headers that help [MailStore](https://sebastian.marsching.com/wiki/MailStore) identify to which e-mail address the e-mail actually belongs, so that it can be archived in the right [MailStore](https://sebastian.marsching.com/wiki/MailStore) account.

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

43

However, for OpenDKIM and [SpamAssassin](https://sebastian.marsching.com/wiki/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:

44

45

`/opt/zimbra/conf/opendkim-localnets.conf.in` (Zimbra 8 only):

46

```

47

%%zimbraMtaMyNetworksPerLine%%

192.0.2.1/32

[2001:db8::1]/128

```

`/opt/zimbra/conf/salocal.cf.in`:

52

```

53

%%uncomment VAR:zimbraMtaMyNetworks%%trusted_networks %%zimbraMtaMyNetworks%% 192.0.2.1/32 [2001:db8::1]/128

54

```

55

56

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`.

57

58

**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](https://sebastian.marsching.com/wiki/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.

59

60

# Mailbox Selected READ-ONLY Error in Thunderbird

61

62

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.

63

64

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:

65

66

```bash

67

zmlocalconfig -e imap_use_ehcache=false

```

# IPv6 and Zimbra 8

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.

73

74

## Fixing the OpenLDAP Problem

75

76

Fixing the OpenLDAP problem is easy: Set the local configuration option `ldap_bind_url` to `ldap:///`:

77

78

```bash

79

zmlocalconfig -e ldap_bind_url=ldap:///

80

```

81

82

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).

83

84

This change should survive minor Upgrades of Zimbra (e.g. from Zimbra 8.0.3 to Zimbra 8.0.5).

85

86

## Fixing the OpenDKIM Problem

87

88

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

89

90

Socket %%zimbraInetMode%%:8465@[%%zimbraLocalBindAddress%%]

to

Socket inet:8465@[127.0.0.1]

95

96

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).

97

98

Unfortunately, this change is overwritten when updating Zimbra, therefore it has to be applied again after each update.

99

100

# Fixing the zmsaupdate cron-job

101

102

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:

103

104

/bin/sh: 28: /opt/zimbra/.bashrc: [[: not found

105

/bin/sh: 36: [: Linux: unexpected operator

106

107

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

108

109

45 0 * * * . /opt/zimbra/.bashrc; /opt/zimbra/libexec/zmsaupdate

to

45 0 * * * /bin/bash -c ". /opt/zimbra/.bashrc; /opt/zimbra/libexec/zmsaupdate"

# SSL / TLS options

## Disabling SSLv3

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.

120

121

For adjusting the list of supported ciphers you might want to refer to the following sites:

122

123

* [http://wiki.zimbra.com/wiki/Cipher_suites](http://wiki.zimbra.com/wiki/Cipher_suites)

124

* [http://wiki.zimbra.com/wiki/Postfix_PCI_Compliance_in_ZCS](http://wiki.zimbra.com/wiki/Postfix_PCI_Compliance_in_ZCS)

125

* [http://wiki.zimbra.com/wiki/Weak_Cipher_Suites_Appear_in_Security_Scans](http://wiki.zimbra.com/wiki/Weak_Cipher_Suites_Appear_in_Security_Scans)

## TLS Ciphers

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):

130

131

```bash

132

zmprov mcf zimbraMtaSmtpdTlsCiphers high

133

zmprov mcf zimbraMtaSmtpdTlsMandatoryCiphers high

134

zmprov mcf zimbraMtaSmtpdTlsExcludeCiphers aNULL,eNULL,LOW,3DES,MD5,EXP,PSK,DSS,RC4,SEED,ECDSA,DES

135

zmprov mcf zimbraMtaSmtpdTlsProtocols \!SSLv2,\!SSLv3

136

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

137

zmprov mcf +zimbraReverseProxySSLProtocols TLSv1.3

138

zmprov mcf -zimbraReverseProxySSLProtocols TLSv1

139

zmprov mcf -zimbraReverseProxySSLProtocols TLSv1.1

140

zmprov mcf +zimbraSSLExcludeCipherSuites SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA

141

zmprov mcf +zimbraSSLExcludeCipherSuites SSL_DHE_DSS_WITH_DES_CBC_SHA

142

zmprov mcf +zimbraSSLExcludeCipherSuites SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA

143

zmprov mcf +zimbraSSLExcludeCipherSuites SSL_DHE_RSA_WITH_DES_CBC_SHA

144

zmprov mcf +zimbraSSLExcludeCipherSuites SSL_RSA_EXPORT_WITH_DES40_CBC_SHA

145

zmprov mcf +zimbraSSLExcludeCipherSuites SSL_RSA_EXPORT_WITH_RC4_40_MD5

146

zmprov mcf +zimbraSSLExcludeCipherSuites SSL_RSA_WITH_DES_CBC_SHA

147

zmprov mcf +zimbraSSLExcludeCipherSuites SSL_RSA_WITH_RC4_128_MD5

148

zmprov mcf +zimbraSSLExcludeCipherSuites SSL_RSA_WITH_3DES_EDE_CBC_SHA

149

zmprov mcf +zimbraSSLExcludeCipherSuites SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA

150

zmprov mcf +zimbraSSLExcludeCipherSuites SSL_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

151

zmprov mcf +zimbraSSLExcludeCipherSuites TLS_DHE_RSA_WITH_AES_128_CBC_SHA

152

zmprov mcf +zimbraSSLExcludeCipherSuites TLS_DHE_RSA_WITH_AES_128_CBC_SHA256

153

zmprov mcf +zimbraSSLExcludeCipherSuites TLS_DHE_RSA_WITH_AES_256_CBC_SHA

154

zmprov mcf +zimbraSSLExcludeCipherSuites TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

155

```

156

157

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:

158

159

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

160

161

We include the CHACHA20 ciphers because some systems that do support them do not support AES256, and they should be better than AES128.

162

163

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.

164

165

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.

166

167

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:

168

169

```bash

170

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"

171

```

172

173

## Strict-Transport-Security Header

174

175

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.

176

177

Typically, the `add_header` option needs to be added to two files:

178

179

* `/opt/zimbra/conf/nginx/templates/nginx.conf.web.https.default.template`

180

* `/opt/zimbra/conf/nginx/templates/nginx.conf.web.https.template`

181

182

The option is added in the following form and add it right after the `ssl_verify_depth` option:

183

184

add_header Strict-Transport-Security max-age=15768000;

185

186

Since Zimbra 8.7 there is a simpler option for adding this header:

187

188

```bash

189

zmprov mcf +zimbraResponseHeader "Strict-Transport-Security: max-age=15768000"

190

```

191

192

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):

193

194

```bash

195

zmprov ms <server> zimbraReverseProxyMailMode redirect

196

```

197

198

You also might have to configure the protocol and hostname used for generating URLs (otherwise, some generated URLs might use the http scheme):

199

200

```bash

201

zmprov md <domain> zimbraPublicServiceHostname <server>

202

zmprov md <domain> zimbraPublicServiceProtocol https

203

```

204

205

## Adjusting the DH key size

206

207

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.

208

209

First, the DH parameters need to be generated with OpenSSL:

210

211

```bash

212

openssl dhparam -outform PEM -out /opt/zimbra/conf/dhparam2048.pem 2048

213

```

214

215

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:

216

217

* `/opt/zimbra/conf/nginx/templates/nginx.conf.mail.template`

218

* `/opt/zimbra/conf/nginx/templates/nginx.conf.web.admin.default.template`

219

* `/opt/zimbra/conf/nginx/templates/nginx.conf.web.admin.template`

220

* `/opt/zimbra/conf/nginx/templates/nginx.conf.web.https.default.template`

221

* `/opt/zimbra/conf/nginx/templates/nginx.conf.web.https.template`

222

* `/opt/zimbra/conf/nginx/templates/nginx.conf.web.sso.default.template`

223

* `/opt/zimbra/conf/nginx/templates/nginx.conf.web.sso.template`

224

225

The configuration line should look like this:

226

227

ssl_dhparam /opt/zimbra/conf/dhparam2048.pem;

228

229

Starting with Zimbra 8.7, Zimbra uses 2048 bit DH params by default and this manual intervention is not necessary any longer.

230

231

# Fixing the logrotate script

232

233

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:

234

235

/etc/cron.daily/logrotate:

236

gzip: stdin: file size changed while zipping

237

238

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:

239

240

postrotate

241

kill -USR1 `cat /opt/zimbra/log/nginx.pid 2> /dev/null` 2> /dev/null && sleep 5 || true

242

endscript

243

244

If this does not help, the `delaycompress` option should fix it for sure.

245

246

# Enabling SpamAssassin rule updates

247

248

Since Zimbra 8, it might be necessary to explicitly enable [SpamAssassin](https://sebastian.marsching.com/wiki/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`:

249

250

```bash

251

zmlocalconfig -e antispam_enable_rule_updates=true

252

zmlocalconfig -e antispam_enable_restarts=true

253

zmlocalconfig -e antispam_enable_rule_compilation=true

254

```

255

256

The last line is only necessary if you want to compile rules (this should improve the scan performance).

257

258

# Adding Pyzor and Razor to SpamAssassin

259

260

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.

## Pyzor

Install the package (as root):

265

266

```bash

267

aptitude install pyzor

268

```

269

270

Create a symbol link in the Zimbra directory (as root):

271

272

```bash

273

ln -s data/pyzor /opt/zimbra/.pyzor

274

```

275

276

Run **all remaining actions** as the **zimbra** user (`su - zimbra`).

277

278

Create the configuration directory:

279

280

```bash

281

mkdir /opt/zimbra/data/pyzor

282

```

283

284

Create a symbol link in the amavisd directory:

285

286

```bash

287

ln -s ../pyzor /opt/zimbra/data/amavisd/.pyzor

288

```

289

290

Optionally, increase the timeout for Pyzor by adding the `pyzor_timeout` option to the [SpamAssassin](https://sebastian.marsching.com/wiki/SpamAssassin) configuration. For example:

pyzor_timeout 20

In recent Zimbra versions, you can add this line to `/opt/zimbra/data/spamassassin/localrules/sauser.cf`.

## Razor

Install the package (as root):

299

300

```bash

301

aptitude install razor

302

```

303

304

Create a symbol link in the Zimbra directory (as root):

305

306

```bash

307

ln -s data/razor /opt/zimbra/.razor

308

```

309

310

Run **all remaining actions** as the **zimbra** user (`su - zimbra`).

311

312

Create the configuration directory:

313

314

```bash

315

mkdir /opt/zimbra/data/razor

316

```

317

318

Create a symbol link in the `amavisd` directory:

319

320

```bash

321

ln -s ../razor /opt/zimbra/data/amavisd/.razor

322

```

323

324

Initialize the configuration:

```bash

razor-admin -create

razor-admin -discover

329

razor-admin -register

330

```

331

332

# Using the ClamAV Unofficial Signatures

333

334

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:

335

336

```bash

337

ln -s clamav-unofficial-sigs-5.4.1 /opt/zimbra/clamav-unofficial-sigs

338

chmod a+x /opt/zimbra/clamav-unofficial-sigs/clamav-unofficial-sigs.sh

339

```

340

341

All remaining steps should be done as the `zimbra` user.

342

343

Create directories for the script’s configuration and data:

344

345

```bash

346

mkdir /opt/zimbra/conf/clamav-unofficial-sigs

347

mkdir /opt/zimbra/data/clamav-unofficial-sigs

348

```

349

350

Copy the `master.conf` and example `user.conf` from the distribution to the configuration directory:

351

352

```bash

353

cp /opt/zimbra/clamav-unofficial-sigs/config/master.conf /opt/zimbra/conf/clamav-unofficial-sigs

354

cp /opt/zimbra/clamav-unofficial-sigs/config/user.conf /opt/zimbra/conf/clamav-unofficial-sigs

355

```

356

357

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.

358

359

```bash

360

# This file contains os configuration settings for clamav-unofficial-sigs.sh

361

###################

362

# This is property of eXtremeSHOK.com

363

# You are free to use, modify and distribute, however you may not remove this notice.

364

# Copyright (c) Adrian Jon Kriel :: admin@extremeshok.com

365

##################

366

#

367

# Script updates can be found at: https://github.com/extremeshok/clamav-unofficial-sigs

368

#

369

# Originially based on:

370

# Script provide by Bill Landry (unofficialsigs@gmail.com).

371

#

372

# License: BSD (Berkeley Software Distribution)

#

##################

#

# NOT COMPATIBLE WITH VERSION 3.XX / 4.XX CONFIG

377

#

378

################################################################################

379

# SEE MASTER.CONF FOR CONFIG EXPLAINATIONS

380

################################################################################

381

# Rename to os.conf to enable this file

382

################################################################################

# Zimbra

clam_user="zimbra"

clam_group="zimbra"

clam_dbs="/opt/zimbra/data/clamav/db"

390

391

clamd_pid="/opt/zimbra/log/clamd.pid"

392

393

clamd_restart_opt="/opt/zimbra/bin/zmclamdctl restart"

394

395

clamd_reload_opt="/opt/zimbra/common/bin/clamdscan --config-file=/opt/zimbra/conf/clamd.conf --reload"

396

397

clamscan_bin="/opt/zimbra/common/bin/clamscan"

398

399

#clamd_socket="/var/run/clamav/clamd.ctl"

400

401

work_dir="/opt/zimbra/data/clamav-unofficial-sigs"

402

log_file_path="/opt/zimbra/log"

403

404

# https://eXtremeSHOK.com ######################################################

405

```

406

407

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:

408

409

securiteinfo_enabled="no" # SecuriteInfo

410

malwarepatrol_enabled="no" # Malware Patrol

411

downloader_ignore_ssl="no" # do not ignore SSL (certifcate) errors when

412

# downloading files

413

414

Finally, one has to add the following line to the `crontab` file of the `zimbra` user (`crontab -u zimbra -e`):

415

416

# Update unofficial ClamAV signatures

417

45 * * * * /bin/bash /opt/zimbra/clamav-unofficial-sigs/clamav-unofficial-sigs.sh -c /opt/zimbra/conf/clamav-unofficial-sigs >/dev/null

418

419

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`).

420

421

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).

422

423

# Use Zimbra for system mail

424

425

The paths are for Zimbra 8.7:

426

427

```bash

428

update-alternatives \

429

--install /usr/sbin/sendmail mta /opt/zimbra/common/sbin/sendmail 25 \

430

--slave /usr/bin/mailq mta-mailq /opt/zimbra/common/sbin/mailq \

431

--slave /usr/bin/newaliases mta-newaliases /opt/zimbra/common/sbin/newaliases \

432

--slave /usr/share/man/man1/mailq.1.gz mta-mailqman /opt/zimbra/common/share/man/man1/mailq.1 \

433

--slave /usr/share/man/man1/newaliases.1.gz mta-newaliasesman /opt/zimbra/common/share/man/man1/newaliases.1 \

434

--slave /usr/share/man/man8/sendmail.8.gz mta-sendmailman /opt/zimbra/common/share/man/man1/sendmail.1 \

435

--slave /usr/share/man/man5/aliases.5.gz mta-aliasesman /opt/zimbra/common/share/man/man5/aliases.5

436

```

437

438

# Synchronizing contacts with the macOS Contacts app (CardDAV)

439

440

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.

441

442

# Remove submitting clients IP address from headers

443

444

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.

445

446

We add the following lines to `/opt/zimbra/conf/postfix_header_checks.in`:

447

448

/^Received:.*with ESMTPSA/

IGNORE

/^X-Originating-IP:/

IGNORE

Please note that there is a tab (not spaces) in front of `IGNORE`.

454

455

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):

456

457

```bash

458

zmprov mcf zimbraMtaBlockedExtensionWarnRecipient FALSE

459

```

460

461

The other solution is changing the configuration of `zmconfigd` by removing the following lines from `/opt/zimbra/conf/zmconfigd.cf`:

462

463