Milter-greylist

Hello,

I work for Universitat Pompeu Fabra, a medium size university from 
Barcelona. We have been using milter-greylist for more than a year with 
a great success, eliminating about the 80% of the incoming spam. Thank 
you guys!

One of the features we miss is the ability to control the amount  of  
messages that users and pc's from our network can send each day, because 
sometimes compromised accounts or virus-infected machines send spam 
through our mail servers. We have been evaluating Policyd [1] for 
message accounting, but it's seems a waste of resources to store again 
the traffic information as we already have it in milter-greylist.

The syntax in greylist.conf could be something like this:

# Each "normal-user" can only send e-mails to 1000 destinations each day
# and the sum of all the messages cannot be over 500MB
racl greylist from list "normal-user" accounting period 24h 
message-count-limit 1000 message-size-limit 500MB msg "Daily limit 
exceeded"

# Each "normal-pc" can only send 200 e-mails/hour. When it reach the limit
# we ask to send later until the beginning of the next period.
racl greylist list "normal-pc" accounting period 1h message-count-limit 
200 msg "Hourly limit reached. Try later"

# Each machine coming from a "problematic-domain" can only send 10 
e-mails/hour.
# When it reach the limit we ask to send later until the beginning of 
the next period.
racl greylist list "problematic-domains" accounting period 1h 
message-count-limit 10

What do you think?

Regards,
Jorge

[1] 
http://www.policyd.org/tiki-index.php?page=Accounting&structure=Documentation

On Thu, Feb 12, 2009 at 10:02:52AM +0100, Jorge Garc\ufffda Oncins wrote:
> The syntax in greylist.conf could be something like this:
> 
> # Each "normal-user" can only send e-mails to 1000 destinations each day
> # and the sum of all the messages cannot be over 500MB
> racl greylist from list "normal-user" accounting period 24h 
> message-count-limit 1000 message-size-limit 500MB msg "Daily limit 
> exceeded"

What about defining the accounting rules at the beginning of the config
file and reuse them later?

# accounting "<rule name>" "<key>" (msgsize|msgcount) <limit> <duration>
accounting 'usracct" "%f" msgsize >= 300MB 24h
(...)
racl blacklist list "users" accounting "usracct" msg "too many messages"


Here we would maintain a size count of messages for each sender (%f). 
The use of a format string enable accounting against whatever you want 
(IP, sendr, receiver...).

Problem: do we just reset counters every <duration> (here, 24h)? Or do
we try a sliding count? That would be much heavier to implement.


-- 
Emmanuel Dreyfus
manu@...

Sliding count would be nice and for this we could reuse the existing
database of tuples so no heavy extra effort should be necessary.
The only problem is, that normally those whitelisted tuples are not
stored so implementing this would mean more memory hungry milter-greylist...
Ondrej
Emmanuel Dreyfus wrote:

>
> On Thu, Feb 12, 2009 at 10:02:52AM +0100, Jorge Garc�a Oncins wrote:
> > The syntax in greylist.conf could be something like this:
> >
> > # Each "normal-user" can only send e-mails to 1000 destinations each day
> > # and the sum of all the messages cannot be over 500MB
> > racl greylist from list "normal-user" accounting period 24h
> > message-count-limit 1000 message-size-limit 500MB msg "Daily limit
> > exceeded"
>
> What about defining the accounting rules at the beginning of the config
> file and reuse them later?
>
> # accounting "<rule name>" "<key>" (msgsize|msgcount) <limit> <duration>
> accounting 'usracct" "%f" msgsize >= 300MB 24h
> (...)
> racl blacklist list "users" accounting "usracct" msg "too many messages"
>
> Here we would maintain a size count of messages for each sender (%f).
> The use of a format string enable accounting against whatever you want
> (IP, sendr, receiver...).
>
> Problem: do we just reset counters every <duration> (here, 24h)? Or do
> we try a sliding count? That would be much heavier to implement.
>
> -- 
> Emmanuel Dreyfus
> manu@... <mailto:manu%40netbsd.org>
>
>

Hi,

 >What about defining the accounting rules at the beginning of the config
 >file and reuse them later?
That's a good idea

 >Problem: do we just reset counters every <duration> (here, 24h)? Or do
 >we try a sliding count? That would be much heavier to implement.

To me reseting all the counters every period will be enough. Maybe the 
<duration> could be changed to <period>  (hourly, daily, weekly, 
monthly, yearly)

Regards,
Jorge

On Thu, Feb 12, 2009 at 11:56:28AM +0100, Jorge Garc\ufffda Oncins wrote:
> To me reseting all the counters every period will be enough. Maybe the 
> <duration> could be changed to <period>  (hourly, daily, weekly, 
> monthly, yearly)

Well, we already have code for entering 1h, 1d, 1w etc... so let's reuse
it. 

-- 
Emmanuel Dreyfus
manu@...

On 02/12/2009 04:25 AM, Emmanuel Dreyfus wrote:
> Problem: do we just reset counters every <duration> (here, 24h)? Or do
> we try a sliding count? That would be much heavier to implement.
>   
Using a token bucket algorithm might be a good choice. It handles bursts 
well and it's fairly light to implement.

On the down side, it's less intuitive to configure.

-John