Nguyen Nang Thang via Users <[email protected]> wrote: > I research that the "MessageCumulativeSize" of quota module can track > cumulative size of email messages > during a period of time. > I'm not sure that it can support tracking cumulative size of email messages > in real time or not?
Yes it does, but it's not exactly obvious at first glance how it works. Say you set a quota of 60 messages/hour - that doesn't mean that the user can send exactly 60 messages between 8am and 9am, then 60 between 9am and 10am, and so on. I've used message counts here, but cumulative message size works just the same. It's done as a "leaky bucket". As messages are passed, the bucket is filled, and the bucket leaks down at the rate specified - and if the bucket is full, then future messages are blocked until it leaks down again. So with the above settings, the user can quickly send 60 messages - this will fill the bucket. They can actually send 61 as the test is "is the bucket filled above the line. Then as the bucket leaks down they can keep sending messages at roughly one per minute - or they can wait a while and send another burst. But *ON AVERAGE* they can't send more than 60/hour. The way the rate is specified matters. 1/minute, 60/hour, 120/2hours, 1440/24hours are all the same rate - one message per minute average. The difference is the initial burst they can send. 1/minute would be very restrictive and would block a lot of normal mail - send a message to 3 recipients and it'll fail. 1440/day allows a burst of near 1 1/2k messages before it starts throttling - it'll let more compromised mail through if the user account is hacked, but it'll suit someone (say) running a small club who needs to send emails occasionally to a few hundred users. > As you know, it does not have a specific of time for end users to send a > message, they can send message(s) > any time via webmail or via email client. All messages are tracked as long as they are received via SMTP. Messages injected locally don't go through Policyd - but that really only applies to messages generated locally on the server. Webmail will normally use SMTP. > My goals: > * normal users can send message size of 5MB (for example). > * special users can send message size of 10MB (for example). > * and all above type of message sizes can be tracked by quota module in real > time whenever they send message > to internal users or to the Internet. That's doable. I find it best to setup several policies which are mutually exclusive - I find the inheritance rules when multiple policies match tricky to manage and so avoid that. So have a group of users to be in the larger class, and define policies matching : - SASL senders and not members of group - SASL senders and member of group - Not SASL auth (inbound) These three are mutually exclusive (I actually have some others on my system). When a user complains that they can't send mail, assuming they qualify, you add their SASL username to the group and they automatically shift to the higher quota. My complete setup is : Policy Inbound ; match !$*,!%internal_ips Policy SASL Users : match !%Int_Network,!%hi-vol-sasl,$* Policy SASL high volume users: match %hi-vol-sasl Policy Internal SASL: match %Int_Network,$*,!%hi-vol-sasl - this is internal systems using SASL Policy Local mail: match %internal_ips - locally generated mail (ie from this machine) Group internal_ips: 127.0.0.0/8 Group Int_Network: 192.168.1.0/24 (add the IP ranges used internally) Group hi-vol-sasl: add list of users in teh form "[email protected]" - the "$" is important as it signifies to use the SASL auth name. Then it's just a matter of setting the quotas accordingly. Hope this helps. _______________________________________________ Users mailing list [email protected] http://lists.policyd.org/mailman/listinfo/users_lists.policyd.org
