Nigel Kukard wrote: OK, so allowing for differences in terminology - where I write "allow", what I mean is doesn't defer (the action set). In this case, it either allows it (the policy does nothing), or it doesn't allow it (defer action).
> > I've now redirected one of my list servers to my new mail host - but >> I've hit a problem with policy matching. >> >> In the mail log, I'm seeing : > > cbpolicyd[2409]: module=Quotas, action=defer, ..., >> reason=quota_match, policy=6, quota=3, limit=11, track=xxx, >> counter=MessageCumulativeSize, quota=0/10000000 (0.0%) > > >> That seem to be saying it's applied the quota for policy ID 6 and >> it's (correctly) failed - the quota on that policy is insufficient >> for the volume of mail from that list server. >> >> When I look in cbpolicyd.log, I see (amongst all the other stuff) : > > DEBUG: END RESULT: prio=0 => policy ids: 1 >> DEBUG: END RESULT: prio=50 => policy ids: 6 >> DEBUG: END RESULT: prio=55 => policy ids: 9 >> DEBUG: END RESULT: prio=60 => policy ids: 7 > > >> Now that tells me that the message matched two higher priority >> policies - and both of those have quotas defined which would allow >> the volume of messages. >> >> >Ok ... first ... it doesn't "allow" the message, it simply doesn't do >anything. > > >> >> NOw, having left it over an hour (I was in a meeting) so the quotas >> are reset, and then flush the queue on the list server, I see in the >> mail log : >> >> module=Quotas, mode=update, ..., reason=quota_update, policy=1, >> quota=4, limit=5, track=SenderIP:xxx0/24, counter=MessageCount, >> quota=4/600 (0.7%) >> >> module=Quotas, mode=update, ..., reason=quota_update, policy=1, >> quota=4, limit=6, track=SenderIP:xxx/24, >> counter=MessageCumulativeSize, quota=0/26214400 (0.0%) >> >> module=Quotas, mode=update, ..., reason=quota_update, policy=6, >> quota=3, limit=4, track=SASLUsername:xxx, counter=MessageCount, >> quota=4/10 (44.4%) >> >> module=Quotas, mode=update, ..., reason=quota_update, policy=6, >> quota=3, limit=11, track=SASLUsername:xxx, >> counter=MessageCumulativeSize, quota=0/10000000 (0.0%) >> >> module=Quotas, mode=update, ..., reason=quota_update, policy=9, >> quota=7, limit=9, track=SASLUsername:xxx, counter=MessageCount, >> quota=4/60 (7.4%) >> >> module=Quotas, mode=update, ..., reason=quota_update, policy=9, >> quota=7, limit=12, track=SASLUsername:xxx, >> counter=MessageCumulativeSize, quota=0/100000000 (0.0%) >> >> module=Quotas, mode=update, ..., reason=quota_update, policy=7, >> quota=5, limit=7, track=SASLUsername:xxx, counter=MessageCount, >> quota=4/3600 (0.1%) >> >> module=Quotas, mode=update, ..., reason=quota_update, policy=7, >> quota=5, limit=10, track=SASLUsername:xxx, >> counter=MessageCumulativeSize, quota=0/10000000 (0.0%) >> >> >> So it appears to be matching the right policies, updating the right >> quota trackings, but then it's applying the wrong limit. >> > >Applying the wrong limit? how so? OK, the message matches policy ID 7. The quota associated with policy id 7 is well above what should cause the message to be blocked, but the message is being blocked by a quota associated to the lower priority policy id 6. What's more confusing is that, according to the logs, the above quota updates happened until the 10th recipient was processed, and then further recipients were deferred - but not by the message count quota (limit=4) attached to policy 6, but by the message size quota (limit=11) which hadn't been exceeded. As I posted earlier : > > cbpolicyd[2409]: module=Quotas, action=defer, ..., > > reason=quota_match, policy=6, quota=3, limit=11, track=xxx, > > counter=MessageCumulativeSize, quota=0/10000000 (0.0%) action=defer -> the message was blocked policy=6 -> the test failed was against a policy that shouldn't be having an effect. > >> Can anyone tell me why the messages are getting deferred by policy 6, >> limit 11, when they should be getting allowed by the higher priority >> policy 7 and limit 7/10 ? >> > >Its not "allowed", messages exceeding quotas will take the action you >define, if they don't exceed the quotas, nothing will happen. > >Maybe this clears up how the quotas work slightly? Not really. I have a policy, the message matches it, there is a quota rule for that policy, yet a quota rule for a lower priority policy appears to be applied. Doing some more checks later on, I raised the quota limits for policy 6, and then a different quota check blocked the messages. Have I missed something obvious here ? In this case, the message matches four policies : DEBUG: END RESULT: prio=0 => policy ids: 1 DEBUG: END RESULT: prio=50 => policy ids: 6 DEBUG: END RESULT: prio=55 => policy ids: 9 DEBUG: END RESULT: prio=60 => policy ids: 7 All four policies have a quota defined against them, therefore as I understand it, only the quota defined for policy 7 should be applied. Eg, policy 9 quotas should only apply if policy 7 doesn't have a quota defined, and policy 6 quota should only apply if policies 7 AND 9 do not have quotas defined, and so on. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. _______________________________________________ Users mailing list [email protected] http://lists.policyd.org/mailman/listinfo/users
