> 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). >
cool > >> > 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. > Thats right, if you have 2 quotas assigned which match the same policy, both will be checked. There is an option in r348+ and v2.1.x which says "Stop processing here" this will prevent any quotas being processed past this match. > 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. > Message size is only updated once the message has been received, ie. End Of Data ... it is allowed as you cannot reject per recipient at this stage, and you only know the size after EOD. When the RCPT stage occurs again and the size is in excess of the quota, it will trigger the quota action. Message count is rejected at RCPT stage as soon as it exceeds the limit, the counter is updated even if the message does not go through EOD. > 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. > Which version of policyd? This is indeed a very odd message to receive. If you can show me how to reproduce, maybe with NC and a few raw smtp files I can fix it. I'm just unable to reproduce it on our test system. >> >>> 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. > No ... they all will be if they have quotas set for each of them, the first to match will trigger the action (defer more than likely). > 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. > Urmm .... all quotas applied to all policies matched will be checked in order, then updated, then checked for exceeding of the quota. -N _______________________________________________ Users mailing list [email protected] http://lists.policyd.org/mailman/listinfo/users
