Jagannath Naidu <[email protected]> wrote: > Dear all, > > Please help > After testing it for two days, I found that the "Quota" works as > 1. Total size of all mails within a specified time "period". The time > specified in seconds "eg 3600 for one hour", policyd sets a counter > and keeps adding mail sizes until it reaches the limit. > > 2. Total number of mails within a specified time "period". Same is > with this limit.
It's not that simple. It's more like a "leaky bucket" - as mails are passed then tokens are added to the bucket, but as time passed they leak out of the bottom. So say you set a limit of 3600/hour or one/second. The user can immediately send 3600 mails at which point the bucket is full and further mails will be blocked. But the bucket leaks away and the user can send another mail after a second - and so on at a rate of one per second indefinitely. So in the first hour you will find that they can send 7200 mails if they send a flood to start with. But over a longer period, they cannot exceed an AVERAGE of 3600/hour. Message counts and message sizes work a bit differently. I'll start with size as that's simplest. For message size, the decision whether to allow or pass a mail is done at each "rcpt to:" - but the tracking table is only updated when the message size is known (at end of data). So you can exceed the quota with a large message - BUT you will then be blocked until the average rate has dropped sufficiently. Message count is slightly more complicated - and depends on your Postfix configuration. The quota gets updated and the decision made at each "rcpt to:" - so for a message to 20 recipients, the counter would start (for ease of explanation) at zero and increment to 1, then 2, then 3, and so on until the 20th recipient is processed. It's entirely possible that some recipients will be accepted, the quota is reached, and then further recipients are rejected. This is where your Postfix config comes into play. If, like me, you impose an error limit on messages - then after a number of rejections Postfix will reject the entire message to all recipients. But because the quota has already been updated, you never actually get to a point where the entire message can be accepted. I had set my error limit to 3 as part of my spam control measures - so when a customer was sending a mailshot to 50 recipients at a time, they'd hit their quota, then Postfix would reject each message - it could only pass a message if there was enough quota for 47 recipients plus 3 rejections, but in practice it would never get to that stage and mail stopped altogether. However, the default setting in postfix is for a much larger error limit - so in practice what happens is that under these conditions the messages are accepted a few recipients at a time. The first few recipients get accepted, the rest rejected once over quota, and the sending server will retry for the remaining recipients after a delay. For a mail client, this will cause a lot of lot of helpdesk calls ! > As opposed to that, my requirements are > 1. That a user can not send mail that exceeds the mail size limit. > "Message cumulative size" > my work : I set the mail size limit to 3 MB. with time period 60 seconds. > observation: When I send a mail of 2 MB, it passes by. When I send a > second mail of 2 MB within 60 seconds, policyd blocks it (GOOD) > problem : when I send mail larger than 3 MB at first, it passes by (BAD) As explained above - that is correct operation. have you checked the Postfix maximum message size limit ? > 2. That a user can not send mails to number not more than specified > "Message Count" > my work : I set the "Message count" to 20, within 3600 seconds. > observation: When I send mail to 15 recipients at first. And then sent > second mail to 10 recipients, policyd blocks it (GOOD) > problem : when I sent mail to 21 recipients at first attempt, it passes by > (BAD) As above, this is correct. When the 21st recipient is processed, the user will not be over quota - it will be 20/20 or in practice slightly smaller since the "bucket is leaking" all the time. If you tried to 22 recipients, you should see the 22nd rejected while the first 21 are accepted. Where the connected source is a mail server this is not a problem - it'll retry the 22nd recipient later. Where the connected source is a mail client it's not ideal - the user will get an error message, but the message will have been sent to 21 of the recipients. For this reason, it's best to have larger numbers over a larger time period - taking your numbers, 40 over 7200 seconds would be better than 20 over 3600 seconds. However, 20/hours is a very low limit. > Also please share, if there is a way of detecting the mail size limit > per user (like from the ldap attribute). As there is no need to set > counters. Not per user, but you can do it by groups. I would very strongly recommend against per-user limits - at most have 2 or 3 policies and assign users to them. Anything else is just making a management headache for yourself. _______________________________________________ Users mailing list [email protected] http://lists.policyd.org/mailman/listinfo/users_lists.policyd.org
