"John G. Heim" wrote: >I would like to keep a spammer from sending out too many messages when >one of my end users gives them their user name and password. I have all >these users on my mail system that fall for phishing scams all the time. >They give some spammer their user name and password and the spammer >uses our mail server to send out bzillions of mail messages.
With us it's normally an end user getting infected with something that then squirts 10s of k of messages into their Exchange which then relays it out via us. Gret fun - disable the account, put all messages on hold, then write a script to go through the whole queue deleting the spam and releasing everything else. >I'm a little confused as to how to do that with cluebringer. My mail >server is debian wheezy with postfix. I installed cluebringer via >apt-get. Everything looks good except I'm not sure how to create a >policy via the web interface. Looking at the wiki, it explains how to >put the message count in the cluebringer.conf ile in the [Quota] stanza. >But the Quota config part of the webui doesn't seem to have any place to >configure that. It could be that I'm missing something because I'm blind >and I am listening to the webui via a screen reader. But here is what I >think I've entered: As it happens, I'm running Wheezy as well, and yes it can all be done via the GUI. It's understandable to be a bit confused, some of the config options aren't necessarily intuitive. I'll describe my setup and hopefully you can take it from there. First stop, the policies. I believe some of the checks are supposed to work on the "highest priority matching policy applies", but some seem to apply all matching policies. So it's a good idea to make your policies mutually exclusive - so only one can match any message. I have 5 policies : Inbound SASL Users SASL Users high volume Internal SASL Local Inbound is for inbound mail, Internal SASL is for my internal systems, and Local is for locally generated mail. Then the bit you are most interested in : SASL Users is for the end users, and SASL Users high volume is for a handful who legitimately send larger volumes of mail. For bevity, I'll refer to them as Inbound, SASL, HiVol, Internal, and Local. Inbound policy has members of "!$*,!%internal_ips" which means it matches all mail that is not SASL authenticated AND is not in the group called internal_ips. SASL policy has members "!%My_Network,!%hi-vol-sasl,$*" which means it matches SASL authenticated messages which don't match groups hi-vol-sasl or My_Network. HiVol policy has members "%hi-vol-sasl" which means it matches group%hi-vol-sasl - you can see that this is mutually exclusive with the main SASL policy. Internal policy has members "%My_Network,$*,!%hi-vol-sasl" which means it matches members of groupMy_Network which SASL authenticate and are not members of hi-vol-sasl. This is for my own systems which have different quotas to outside customers. And Local policy has members "%internal_ips' meaning it matches members of group internal_ips. Now, the group members. My_Network contains entries of the form "a.b.c.d/s" - so it matches all the subnets I want to treat as "local" internal_ips just has one entry "127.0.0.0/8" so it matches localhost And the key one, hi-vol-sasl contains entries of the form "[email protected]" - note the leading $ which signifies an SASL username. If I want to allow a customer to send a higher volume of mail then I just add their email address to this group. You now have 5 policies which are mutually exclusive, and which allow you two categories of customer. You can now create a Quota for each of them. For quotas, in the quota definition you specify the timescale over which the quota should operate, and what should happen if it matches - eg 3600s (one hour) and Defer. You then add limits (message count or message cumulative size) which apply during that period. For example, in my HiVol quota I have 1800 messages and 100M cumulative size in that one hour - the message count is higher than I'd like, but more on that in a minute. Hopefully that explains things a bit ! Now, a note on quota limits. Message cumulative size is applied at the end of message handling (ie at the smtp end of data stage). Ie, the system receives the message, and when the whole message has been received, the cumulative size register is updated (actual message size times number of recipients). This is fine - while it would allow a massive overshoot (large message to lots of recipients), the quota would then block (defer) until the register bleeds down to within the quota limit. Message count is done at smtp recipient stage - ie each time the sender says "rcpt to: <some address>", the message count register is incremented. Once the quota limit is reached, then further recipients are deferred. However, if you have tweaked Postfix then this causes a problem that can completely block mail from a sender. A scenario for this is : User hits the message count quota, so Policyd starts deferring recipients. User is sending messages to 50 addresses per message, so a few addresses are accepted, but then the rest are deferred. Each deferral counts as an error to Postfix, so aftersmtpd_hard_error_limit recipients are deferred, Postfix terminates reception of the message by closing the connection. Of course, the recipients that had been passed by Policyd count towards keeping the message count register topped up - but they aren't actually handled. So the quota is kept "fully used" without actually passing any traffic. As I hadsmtpd_hard_error_limit set to 3, this meant a complete block happened ! You can setsmtpd_hard_error_limit higher - in fact it needs to be at least as high assmtpd_recipient_limit to avoid this problem. You can then setsmtpd_soft_error_limit andsmtpd_error_sleep_time so that Postfix will delay after each recipient deferral which has the effect fo throttling down the process fo receiving the list of recipients while the user is up to quota. IMO, it would be better if the message count register was also updated at the smtp end of data stage, and I have put a request in for this. Whether it will get changed is down to whether Nigel decides (and has time) to do it. Such a change would allow the user to go over-quota bysmtpd_recipient_limit with one message - but then they'd be blocked completely until the register drains down. Personally I think this would actually be better. And finaly, a note on how the quotas work. Think of it like a bucket - each entity (ie the unit you've decided to apply quotas on, in this case the SASL username) has their own bucket. Each time they send a message, then the quantity is added to the bucket - for message count the bucket is incremented by 1, for message size the size * number of recipients is added. When the level in the bucket is above the limit set for the quota then further messages are deferred. But the bucket has a hole in it, so it slowly leaks down. This means that if the bucket is empty, the sender can sent a large volume of mail very quickly - so with the figures given above, a sender could send 1800 messages as fast as your system can handle it before being blocked. But over a period of time, their average rate cannot exceed the rate you've set. So the limits of 300 messages per 300 second and 3600 messages per 3600 seconds both allow an average of one message per second. For a burst, the first would start throttling after the first 300 messages, the second would only throttle after the first 3600 messages. But long term, both would only allow one message per second. This mostly affects users who are very bursty with their traffic. Someone who has been idle for some time and then sends (say) 2k messages would be able to send them as a burst with the 3600/3600 quota, but would be rate limited with the 300/300 quota. When setting the quotas, consider what your clients are using. If they have their own on-site smtp server then this will just queue and retry the messages when tehy get deferred. When using their desktop client software, they'll get errors and start phoning your support line if they hit their quota. _______________________________________________ Users mailing list [email protected] http://lists.policyd.org/mailman/listinfo/users_lists.policyd.org
