1/3 – Zimbra Open Core Series – Amavis Policy Banks to Set Up a VIP Mailbox

Hello Zimbra Friends,
This blog is educational only. It is a customization to your Zimbra environment and is not supported by Zimbra Support. Please run thoroughly in your test environment before using it in production.
We are happy to bring you part 1 of a 3-part series on Zimbra’s open-source components, a series brought to you by Barry de Graaff, Channel Evangelist at Synacor. The series covers:
  1. Amavis Policy Banks to set up an email address for a VIP
  2. cbpolicyd to set-up rate limiting on outgoing email to enforce a mass mailing guideline
  3. Milter filters to extend postfix

Amavis Policy Banks

Zimbra is built on powerful open-source components. One of these components is Amavis, a piece of software that ties together Postfix, Spam Assassin, ClamAV and so on. Amavis is installed by default in a Zimbra installation. Together with Spam Assassin and ClamAV, it provides basic spam fighting and anti-virus capabilities for your Zimbra email server.

Let’s introduce Amavis policy banks. Policy banks can be useful when you have to tackle a specific use-case or have special network requirements. Policy banks are sets of Amavis configurations that are applied to specific email senders. You can set-up policy banks to allow clients on your internal network to bypass AS/AV scanning, allowing particular senders to attach files that are banned for other senders.

In the example below, I will show you how to use a policy bank to enable sending of bounce messages, but **only** for users on a specific server (network).

Real world example: A VIP mailbox

Recently a Zimbra customer asked me if it was possible to set-up a mailbox for a VIP that only a few users on the server are allowed to email to. All other users should receive a bounce message if they send email to this VIP.

You can do this using an Amavis policy bank.

Set-up the users that are allowed to email the VIP and ban the rest of the users like this:

zmprov ma vip@example.com +amavisWhitelistSender secretary@example.com
zmprov ma vip@example.com amavisBlacklistSender example.com

zmprov -l ga vip@example.com | grep amavis | grep Sender
amavisBlacklistSender: example.com
amavisWhitelistSender: secretary@example.com


This allows secretary@example.com to email vip@example.com. If any other user from @example.com sends an email to vip@example.com, their message is not delivered. But they also will **not** receive a bounce message. This is because the `zimbraAmavisFinalSpamDestiny` setting defaults to `D_DISCARD`. The discard operation basically means throw away without a bounce message. The zimbraAmavisFinalSpamDestiny is reached for email that triggers amavisBlacklistSender or has a high spam score (the “kill percentage”).

The Amavis documentation shows you could change zimbraAmavisFinalSpamDestiny to D_REJECT or D_BOUNCE. In both cases a bounce message will be sent. But we can no longer do this because of the high volume of spam that circulates on the Internet today. Spammers often use incorrect sender and recipient addresses, so the bounce messages would go to many recipients that don’t know us, and our server and domain would be blacklisted very soon.

To work around this we open `/opt/zimbra/conf/amavisd.conf.in` and add `final_spam_destiny => D_REJECT`, to policy bank MYNETS like this:

$policy_bank{'MYNETS'} = { # mail originating from @mynetworks
originating => 1, # is true in MYNETS by default, but let's make it explicit
os_fingerprint_method => undef, # don't query p0f for internal clients
final_spam_destiny => D_REJECT,

This will enable bounce emails ONLY for mail originating from ZimbraMtaMyNetworks, which should be a trusted network. Be careful if there is a possibility of servers/clients on ZimbraMtaMyNetworks that may misbehave as that may result in email loops. If you are worried about that you can use a different or new policy bank.

Don’t forget:

zmamavisdctl restart


1. Changes to `amavisd.conf.in` do not survive Zimbra upgrades, so you must manually reapply then when doing Zimbra upgrades.
2. Email that bypasses AS/AV will not be blocked. If you have issues check `/var/log/zimbra.log`.

Further Reading


Thank you,

Barry de Graaff
Channel Evangelist
Zimbra | A Synacor Product

, , , , , , , , , , , , , , ,

Comments are closed.

Copyright © 2022 Zimbra, Inc. All rights reserved.

All information contained in this blog is intended for informational purposes only. Synacor, Inc. is not responsible or liable in any manner for the use or misuse of any technical content provided herein. No specific or implied warranty is provided in association with the information or application of the information provided herein, including, but not limited to, use, misuse or distribution of such information by any user. The user assumes any and all risk pertaining to the use or distribution in any form of any subject matter contained in this blog.

Legal Information | Privacy Policy | Do Not Sell My Personal Information | CCPA Disclosures