On Mar 4, 2014, at 7:25 PM, Venkat <mvenkat...@gmail.com<mailto:mvenkat...@gmail.com>> wrote:
When a password gets compromised, spam starts to pour out of the server from endless numbers of IP's, to endless numbers of addresses. Rate limiting is interesting but doesn't really stop the spam. Counting client=[IP] addresses until a threshold is reached is highly effective, but then what? Change their password? We are using policyd to manage quotas on e-mail send outs. You can also use a log monitor like swatch to alert you if an account exceeds quota. At this point the account can be disabled till the user changes their password. Also, policyd supports things like rejecting or holding e-mails if the quota is exceeded so spam does not go out anymore. You can also script automatic disabling of accounts based on quota violations. We find that blacklisting usually only happens when a very large number of spam escapes, so rate limiting per account (e-mail address) is quite effective. I’ve got the same problem and I’ve installed policyd on a test server. Using the GUI the setup is simple enough, but I’ve yet to get it to work. Not bing sure whether I need to setup restrictions under Quotas or Accounting I’ve tried both and after I’ve sent a bunch of test messages, the one thing I notice is that nothing is being written to the either the accounting_tracking or the quotas_tracking tables. The policyd log file shows that every message (including those beyond the 5 limit I setup for testing) was processed and the modules both returned a CBP_SKIP which I gather means nothing to do. Did you have that same problem and if so, how did you get around it. ~ Rob
