CBpolicyd
How to configure quotas for cbpolicyd (sqlite).
PolicyD v2 (codenamed "cluebringer") is a multi-platform policy server for popular MTAs. The main goal is to implement as many spam combating and email compliance features as possible. The configuration of cbpolicyd under Zimbra is done by editing the sqlite database as shown in the examples below.
Sqlite contains couple of tables, which are used for the configuration of cbpolicyd:
sqlite> .tables access_control greylisting_tracking accounting greylisting_whitelist accounting_tracking policies checkhelo policy_group_members checkhelo_blacklist policy_groups checkhelo_tracking policy_members checkhelo_whitelist quotas checkspf quotas_limits greylisting quotas_tracking greylisting_autoblacklist session_tracking greylisting_autowhitelist
We will predominantly work with the policies, policy_members, policy_groups, policy_group_members, quotas and quotas_limits tables. First, we need to navigate to and enter the sqlite database:
$ cd /opt/zimbra/data/cbpolicyd/db/ $ sqlite3 cbpolicyd.sqlitedb SQLite version 3.6.20 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite>
To configure cbpolicyd is important to understand the logic flow and the schema structure of the tables, as it might be confusing at the beginning. With the examples below I will also include the schema structure to understand the flow better. There are two possibilities: to configure policy with groups or without groups.
For both possibilities we need to create the following:
1. Create a policy in the policies tables. 2. Configure the policy members of the newly created policy in the policy_members table.
a) If we are not to use groups, then after configuring the policy and policy members, we edit the quota and quotas_limits tables. b) If you are to configure groups, then after configuring the policies, we configure the groups and then the quotas.
Creating policy:
The following command creates policy with name "test_policy", with priority 0 and is enabled:
sqlite> insert into policies(Name,Priority,Disabled) VALUES ('test_policy',0,0);
Priority 0, means it will be picked up first from the list of the policies. The priorities goes as 1, then 2 and so on.
Example of our newly created policy (the ID,Name etc are not included in the normal view, but I put them to see the column name and corresponding data):
sqlite> select * from policies; ID|Name |Priority|Description |Disabled 1|test_policy|0 | |0
Creating policy members:
The next thing to do is to edit the policy_members table, to specify the members that will be included in the policy. We will give two examples: one using group and without.
+ group
sqlite> insert into policy_members(PolicyID,Source,Destination,Disabled) VALUES (1,'%test_group','any',0);
- group
sqlite> insert into policy_members(PolicyID,Source,Destination,Disabled) VALUES (1,'user@mydomain.com','any',0);
The result from these two commands is:
sqlite> select * from policy_members; ID|PolicyID|Source |Destination |Comment|Disabled 1|1 |%test_group |any | |0 2|1 |user@mydomain.com|any | |0
Important to note here is the second column of the policy_members table. It points to the ID number of the policies table. In this case, both entries in the policies_members table point to the same policy: 1, from the policies table.
--IN PROGRESS--