On Jul 24, 2012, at 2:37 AM, Stan Hoeppner wrote: > On 7/24/2012 12:44 AM, CSS wrote: >> >> On Jul 24, 2012, at 1:24 AM, Stan Hoeppner wrote: >> >>> On 7/23/2012 4:16 PM, CSS wrote: >>> >>>> I'd like to take some measures to limit what an authenticated sender can >>>> do but not limit legitimate use. >>> >>> See: >>> http://www.postfix.org/postconf.5.html#smtpd_client_connection_rate_limit >>> >>> You would apply this to your submission service, eg: >>> >>> 587 inet n - n - - smtpd >>> -o smtpd_enforce_tls=yes >>> -o smtpd_sasl_auth_enable=yes >>> -o smtpd_client_connection_rate_limit=1 >>> >>> This limits spammers and legit users to 1 msg/min, 60 msgs per hour. >>> Postfix is not psychic. >>> >>> This may be a problem for roaming users who send batches of mails when >>> they get a connection--10 msgs takes 10 minutes. Thus, as with >>> anything, some analysis and [re]tuning will be required. If you trust >>> some users to never have their acct compromised, you can always create >>> multiple submission services on different ports and have different >>> limits for different sets of users, or even no limits for some. >>> >>> Not a perfect solution, but better than what you have now. > >> If I can cobble this thing together, the quota module offers things like >> messages per day or per hour, which is a fairly reasonable way to restrict >> customers. > > Apparently you didn't read the docs I provided. > http://www.postfix.org/postconf.5.html#anvil_rate_time_unit
I actually have some rate-limiting already, but obviously not enough. > > The time unit over which client connection rates and other rates are > calculated. > > Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). > The default time unit is s (seconds) Perhaps I'm misunderstanding this, but I was under the impression that the anvil limits were all enforced on a per-connection or per-IP limit. I'm really after something that can track a particular sasl-authenticated user and punish them (and not other users). I'll re-read what I can find on anvil again, the recommendations against its use in this situation may have been dated. > >> Are there any other specific policy daemons I've missed that deal explicitly >> with rate-limiting? > > Probably. But I think you summarily discounted the inbuilt Postfix > equivalent too quickly, without even looking at it. You can having it > running in less than 60 seconds. Which I may just do in hopes it can provide a base level of protection. > >> It seems like the internet as whole would certainly benefit from a >> dead-simple policy daemon that could thwart the attempts of spammers using >> hijacked credentials to spew their junk. > > You'd think humans beings would be smart enough to follow directions and > use strong passwords, AV software, etc, and not fall for phishing scams. > Your adversary in this war isn't the spammers, it's not the technology, > but your users. I've worked with end users since 1995. They aren't changing. In fact, the facebook-ization of the internet is bringing us right back to the good old AOL days of walled gardens. Users are getting less, not more savvy. > > You should not be expending any more time/effort on the tech piece of > the solution beyond finding the most basic rate limiting tool and > enabling it to prevent spewage, right now. This is the smallest battle > in this war. Funny, as I was speaking to my partner about this issue and he was wondering why all the spam wars are being fought on the recipient end - so many cpu cycles and hardware to filter the 20% or so of good mail from the bad. He could not grasp why the source of the spam could not be legislated away. > The big battles are user education (AV software on their machines, safe > surfing habits, anti-phish education, etc), and wholesale forcing all > users to change to *enforced* strong passwords. I had suspected a guessable password, and I was wrong. This customer routinely calls in with various issues and the tech that works with them has the password so he can login to webmail as the customer and verify whatever oddity they see. It was not the best, but it was random, mixed-case, mixed numbers and letters. Was it a *unique* password? Probably not... > The user related stuff wins this war. The tech portion merely decreases > the amount of damage per clueless user battle. The war will be lost. TimeWarner, Comcast, Verizon and everyone else is not going to either lose customers by cutting off the ever-infected clueless or spend time (money) educating them... Charles > -- > Stan >
