Tom Kinghorn <[email protected]> wrote: > The first is 180 messages per hour (3600 seconds). > The second is 1500 messages per day (86400) seconds. > > 1.) on testing, i pushed 200 messages through in 5 minutes, which were > blocked after 180. > A few minutes later, I sent again. > A few messages went through but then got blocked again. > Why is this? surely it should have been blocked immediately since an hour > had not lapsed.
To expand on what Nigel wrote- thing of the counters as like leaky buckets - it's not a case of waiting till the end of the hour then tipping the contents out, the contents are leaking out all the time. The upshot is that if you are starting with an empty bucket, you can burst up to (in your case) 180 messages before you fill the bucket. Actually, due to the fact that you won't get 180 messages through in "an instant" and the way the quota works, you'll get at least 181 messages through. If you keep trying, then you'll be able to dribble messages through as the bucket leaks away - at an average rate of 180/hour (or 3/minute, or one every 20 seconds. If you pause for a few minutes you'll be able to burst again until the bucket is full, and then be back to dribbling through. If you are following closely you'll realise that someone could actually get 360 messages through in one hour. But to do this they will have had to send no messages during the previous hour (so the total is only 360 in 2 hours) - thus the long term average rate cannot exceed 180/hour. Ie, you can burst at rates which appear to exceed the quota limit - but long term the average rate will be controlled as specified. > 2.) based on 180 per hour & 1500 per day, when would be the best time to run > the cleanup script? > # /usr/local/bin/cbpadmin --config=/etc/cluebringer.conf --cleanup It's not related. The cleanup script plays no part in how the various modules operate - all it does is remove old stale information from the database. Take the greylisting module for example. For *every* inbound message delivery attempt the system will create or update a record holding the triplet of client-IP,sender-address,recipient-address. Many of these will be spam and you'll never hear of that triplet again. For legitimate messages from properly functioning servers, you will see that again and the record will eventually get upgraded to "authenticated" and messages matching that triplet will be permitted. As you can imagine, on a busy (or even not so busy) server, such records will quickly build up, and that's what cbpadmin --cleanup will deal with. It'll delete old stale records - so unauthenticated which have expired (the client didn't connect again and retry delivery within the timeframe allowed) and authenticated which are also old and stale (you've not received a matching message for more than the period specified). As a side note, I generally find the ratio of unauthenticated/authenticated to be around 4:1 - ie for every message that passes greylisting, there are another 4 that don't ! That's a lot of spam dealt with. So you can run cleanup whenever you want. The more often you run it, the fewer records it'll delete each time. The main consideration is that on a busy server, and with a long period, the database tables will grow and you will have a large number of records to delete. I don't know if any locks are involved, but I've had experiences in the past (not in relation to policyd or MySQL) where I've run out of locks during certain database operations. _______________________________________________ Users mailing list [email protected] http://lists.policyd.org/mailman/listinfo/users_lists.policyd.org
