cbpolicyd and Amavis on Zimbra

The amavis module has the biggest table in cbpolicyd, with more than sixty columns covering spam thresholds, virus and banned-file handling, per-policy whitelists, quarantine destinations and admin notifications. It is also the module least likely to do anything on a stock Zimbra server, and it is worth understanding why before spending an afternoon on it.

Part of the series that starts with cbpolicyd on Zimbra: An Introduction.

What it is for

Unlike every other module, this one does not return a verdict to Postfix. It stores amavis settings, keyed by cbpolicyd policy, so that different senders or recipients get different spam thresholds and handling.

The amavis_rules table covers roughly what amavis itself exposes per policy bank:

Group	Columns
Bypass	bypass_virus_checks, bypass_banned_checks, bypass_spam_checks, bypass_header_checks
Spam thresholds	spam_tag_level, spam_tag2_level, and the related kill and subject settings
Lists	sender_whitelist, sender_blacklist
Quarantine	quarantine_virus, quarantine_banned_file, quarantine_bad_header, quarantine_spam
Notifications	notify_admin_newvirus, notify_admin_virus, notify_admin_spam, and others
Interception	bcc_to

Every setting has a matching _m column controlling how it combines with the value inherited from a lower-priority policy:

_m value	Meaning
0	Inherit, ignore this row's value
1	Merge, valid only for list columns
2	Overwrite

A value set without also setting its _m column to 2 does nothing, because 0 is the default and means inherit. That trips up almost everyone who tries this table.

The catch on Zimbra

cbpolicyd does not push these settings anywhere. It stores them and expects amavis to read them out of the same database, using amavis's own SQL lookup support (@lookup_sql_dsn and the policy bank machinery).

Zimbra does not configure that. Zimbra manages amavisd.conf itself through zmconfigd, with its spam thresholds coming from Zimbra attributes rather than from an external database. So on a stock installation:

• Writing rows into amavis_rules changes nothing.
• zimbraCBPolicydAmavisEnabled being TRUE changes nothing on its own.
• Making it work means pointing amavis at the cbpolicyd database yourself, in a file that Zimbra rewrites, which puts you outside anything Zimbra supports and at risk of losing the change on the next configuration reload or upgrade.

That is a poor trade for most people, and it is the honest answer: this module is a feature of upstream cluebringer that Zimbra's packaging does not wire up.

What to use instead

Almost everything people want from this module already exists in Zimbra, configured the supported way.

Per-domain or per-COS spam thresholds are Zimbra attributes:

# tag and kill thresholds
zmprov mcf zimbraSpamTagPercent 33
zmprov mcf zimbraSpamKillPercent 75

Per-user whitelists and blacklists are account attributes the user can also manage from Preferences:

zmprov ma user@example.com +amavisWhitelistSender partner@example.net
zmprov ma user@example.com +amavisBlacklistSender spam@example.org

Filing by spam score, including sending borderline mail to a review folder rather than Junk, belongs in Sieve and is covered in File Suspected Spam by Its Score. That article also explains the X-Spam-Level trick, which avoids a nasty numeric-comparator trap.

Quarantine is a Zimbra feature in its own right:

zmprov mcf zimbraAmavisQuarantineAccount quarantine@example.com

Per-recipient attachment and content policy is what MSH Zimbra Rules does, during the SMTP session, with an interface and per-domain delegation.

If you still want to try it

The honest prerequisites are: you are comfortable editing amavisd.conf in a way Zimbra may overwrite, you have a way to reapply the change after upgrades, and you are testing on something that is not production. Read the upstream documentation for amavis SQL policy banks first, because the cbpolicyd side is only half the configuration and is the easier half.

The table itself is straightforward once you accept the _m rule. To give one domain a more tolerant spam threshold:

INSERT INTO amavis_rules
  (PolicyID, Name, spam_tag2_level, spam_tag2_level_m, Disabled)
  VALUES
  ((SELECT ID FROM policies WHERE Name = 'Lenient domain'),
   'Higher spam threshold',
   8.0,
   2,      -- overwrite, not inherit
   0);

Without that 2, the 8.0 is ignored.

The short version

Skip this module on Zimbra. Its useful functions are available through supported Zimbra configuration, Sieve, or a milter, and making it work means fighting zmconfigd for control of a file it owns.

It is documented here because it appears in the module list, in the attribute list and in the database, and "why does nothing happen when I write to amavis_rules" deserves an answer.

Next in this series

Troubleshooting cbpolicyd on Zimbra, which is the article to keep open whenever a rule is not doing what you expected.