mod-ticket : A valvula module to control massive mail deliveries by tickets


mod-ticket is a handy module that allows to implement massive mail services controlled by tickets. This tickets acts like quotas where user consume them every time a send operation is done until ticket limit is reached.

At the same time, these tickets allows to define a time limit to be consumed, day limit, month limit and global limits.

NOTE: this module is recommended to be connected to smtpd_data_restrictions to avoid problems with test phase software (which first connects to simulate and then does the final send operation). It can also work in smtpd_end_of_data_restrictions though it is not recommended because your server will have to accept the entire message first to make a final decision.

Connecting the module with postfix to make it usable

Once valvula is installed with this module enabled, you can use the following commands to connect it to postfix:

1) Ensure mod-ticket is available by running:

>> -o
Module: mod-ticket

2) List listeners running this module:

>> -l
Mod: mod-ticket

3) Now connect it to postfix like:

>> -c smtpd_data_restrictions 3579 first

4) Finaly, you have to reload postfix, for example:

>> service postfix reload

Configuring plans to limit sending operations

1) First, you'll have to create the set of plans to apply to your sending users. For that, connect to the valvula database and insert them like:

mysql> INSERT INTO ticket_plan (name, description, total_limit, day_limit, month_limit) VALUES ('You plan name', 'description', 100000, 3000, 10000)

Use -1 for any of the "limits" to disable it. For example, use total_limits == -1 to make total limits to be not applied at let only day_limit and month_limit to be applied. The same applies to the day_limit and month_limit attributes.

2) Now, with that plan created, create a rule that binds this plan to a sending sasl user like this:

mysql> INSERT INTO domain_ticket (sasl_user, valid_until, ticket_plan_id) VALUES ('', -1, plan_id)

...where plan_id is the id inside ticket_plan table and -1 is that you are making this rule to have no limit in time, allowing the user to consume without time ilmit. Otherwise, place there an unix stamp epoch indicating when that user should be blocked even through there's still quota available.

...and that's all.

You don't have to restart valvula after including modifications or updates into the MySQL database. Valvula will notice that this is available on the next incoming request to be checked.

Additional notes

For further notes, please take a look at the implementation at: