[feedquote='Trac','http://trac.i-mscp.net/ticket/1105']
In a lot of cases it is desirable to limit the number of mails a user and/or domain is allowed to send per hour or per day. All major email provides have such functionalities built in, mainly to protect their own servers from abuse.
Example scenarios:
- One client gets his work computer infected with malware. The malware steals her credentials and distributes them to a botnet. Suddently, your server is relaying SPAM emails coming from a large number of clients that use the client's SASL credentials. Your IP gets blacklisted on lots of RBLs, etc.. Painful.
- One of your clients decides that it is a good idea to buy a list of emails and spam them by sending mass promotional emails using her account. This can also get your server's reputation in trouble quickly...
Although it is not a perfect solution, limiting the number of emails that users can send helps a lot at reducing the impact of these scenarios to your server's reputation. Unfortunately, postfix itself does not have such capability, and hence external policy daemons must be used to achieve this goal.
There are two such well-stablished policy daemons:
Postfwd is usually recommended in the postfix's IRC channel and mailing lists. It is a perl daemon that allows you to set rules in a firewall-like fashion. These rules can be used to setup lots of different kinds of filters (RBL-based filters, pure blacklist/whitelist filters, rate-limiting filters and more). The main advantage is that it is a battle-tested solution. The caveat for imscp is that its functionality overlaps a bit with what policyd-weight (that is already in use in imscp) provides.
Policydv2 is another such daemon, also opensource and written in perl. The approach is quite different though. In this case, the daemon contains a number of modules, each serving a different purpose. There are modules for accounting (pure tracking of number of emails sent, sizes, etc.), checking SPF records, performing greylisting, and rate-limiting (which they call quotas) among others. The advantage of this solution is that it could provide and/or replace other functionalities (for instance, we could use it to track usage statistics instead of parsing the mail.log which is filmsy and inaccurate). The caveat is that it would require more work to integrate and it overlaps with current functionality such as postgrey and the current accounting code.
Don't hesitate to contact me if you want to pick this task up and/or discuss it further.
[/feedquote]