Restricting Sending and Receiving Emails for Users in Carbonio Community Edition | Carbonio CE

One of the most important characteristics of an email server is its reputation. If it turns out to be tainted by uncontrolled mass mailing, there is a risk that the letter sent from such a server will not only end up in the Spam folder but will be automatically deleted even before it reaches the server.

One of the most reliable ways to protect your server from loss of reputation is to control the number of emails sent by users so that they do not send out mass spam mailings, and your server name does not add to public blacklists. CBPolicyD allows you to limit the number of emails that users can send. In this article, we will talk about how to set up a limit on sending emails in Carbonio, as well as talk about other features of CBPolicyD.

Cluebringer Policy Daemon is a service for Postfix that allows you to apply various policies on the mail server, including greylisting, and restrictions on receiving and sending mail, both based on recipients and senders, as well as based on hosts and IP addresses. Policies in CBPolicyD are configured in the appropriate database.

CBPolicyD is installed with Carbonio CE, but this module is not enabled by default. To enable it in a single-server infrastructure, you must run this command:

carbonio prov ModifyServer mail.carbonio.tld +zimbraServiceEnabled cbpolicyd

For a multi-server infrastructure, run this command on the MTA servers.

After executing this command, the SQLite database cbpolicyd.sqlitedb will appear in the /opt/zextras/data/cbpolicyd/db folder in which all CBPolicyD data is stored. You can view it with SQLite3: sqlite3 /opt/zextras/data/cbpolicyd/db/cbpolicyd.sqlitedb and the .tables command.

You can view the number of distinct elements in the database using the select * from sqlite_sequence; command

You can view each of the saved elements using a command like select * from policies; and others

As you can see from the output of the commands, policies are regular rows in an SQLite table, which means that adding new policies will be adding new rows to this table.

For example, consider creating a policy that will limit the sending of emails for any senders to 10 emails per minute.

First of all, you need to create a group that will include all senders and recipients, to apply the created policies to it later.

This is done by SQL statements in the policy_members table. To do this, you need to create a policy_members.sql file with the contents of the statement.

BEGIN TRANSACTION;

INSERT INTO "policies" (Name,Priority,Description) 
VALUES('Сarbonio CBPolicyD', 0, 'Carbonio CBPolicyD');

INSERT INTO "policy_members" (PolicyID,Source,Destination) 
VALUES(6, 'any', 'any');

COMMIT;

The first line of the statement adds a new policy with the highest priority to the list of CBPolicyD policies, the second line adds a new group that includes all users and is associated with the policy added in the first line. Please note that the number 6 is used as the PolicyID in the second line. This is because by default Carbonio already has five policies, respectively, the added policy will be the sixth. If you have previously added policies to those that are in Carbonio by default, use the PolicyID that you will have.

Once you’re done, insert SQLite sqlite3 /opt/zextras/data/cbpolicyd/db/cbpolicyd.sqlitedb < policy_members.sql

To create a policy to restrict sending emails, you will also need to create an SQL statement. To do this, create a quota_send.sql file with the following content:

BEGIN TRANSACTION;

INSERT INTO "quotas" (PolicyID,Name,Track,Period,Verdict,Data) 
VALUES (6, 'Sender:user@domain','Sender:user@domain', 60, 'DEFER', 'Deferring: Too many messages sent in last 60 seconds');

INSERT INTO "quotas_limits" (QuotasID,Type,CounterLimit) VALUES(3, 'MessageCount', 10);

COMMIT;

Here we insert rows into the “quotas” and “quotas_limits” tables with the ID of the policy to which the quota applies, the settings for message tracking, the policy period, the limit, and the result of exceeding the policy.

After the SQL statement file is saved, it will be enough just to add it to the policy table:

sqlite3 /opt/zextras/data/cbpolicyd/db/cbpolicyd.sqlitedb < quota_send.sql

You also need to enable CBPolicyD quotas on the server

carbonio prov ms mail.carbonio.ru zimbraCBPolicydQuotasEnabled TRUE

After that, the policy will be applied.

As can be seen from this policy, all letters that will not fit into the allotted limit will be postponed and sent after the limit is updated. Thus, even a hacked account will not be able to send more than 600 messages in an hour, and the administrator will most likely be able to take action by then to solve the problem.

It might seem like a good idea to limit email receipt. For example, a restriction on receiving emails can become a defense against mail bombing. CBPolicyD allows you to limit the acceptance of messages both for an individual user and for an entire domain.

BEGIN TRANSACTION;

INSERT INTO "quotas" (PolicyID,Name,Track,Period,Verdict) 
VALUES (6, 'Recipient:@domain', 'Recipient:@domain', 60, 'REJECT');

INSERT INTO "quotas_limits" (QuotasID,Type,CounterLimit) 
VALUES(4, 'MessageCount', 125);

COMMIT;

In this statement, the number of emails received by domains is limited to 125 per minute, and any messages that exceed this limit are rejected by the server. Such a measure may seem effective in preventing mail bombing or spam attacks on the server, but in fact, it can turn out to be worse and more destructive than the cyberattacks on the mail server themselves, since any spam attack, even the most modest in scale, can stop users from receiving emails. Instead, it is recommended to use Postscreen.