On 16/08/2012 09:11, Cor Bosman wrote:
What would be really cool is if you also kept statistics on certain metrics, like how many emails a specific sender has sent. If this is done right, it could become a centralised spam sender back-off system over multiple smtp servers. Maybe something for the future. We now pay $$$$ for a commercial system that implements this.
The submission servers would need to share state with each others to make this reliable. Some nosql database would work for that I guess (memcached?)
Can you describe more fully what you would want it to do and/or what the current system does? Probably not something I'll implement soon, but would be good to know for future :) They would indeed need to share the state, this is what the commercial system does (Cloudmark Gateway). The idea is to prevent senders to send email beyond certain limits that are configurable. Lets say, 200 emails in a minute, or 500 an hour, or whatever. Of course allowing for whitelists. With ever increasing speeds of residential connections (we have hundreds of fiber connections now, growing rapidly), these become very fast spam sources without something to keep them in check. It's easy on 1 server, not so easy if you have dozens of smtp servers.
But yes, something for a distant future :) And CM has other features as well, so it may not be so easy to replace :)
My opinion is that this is very easily to implement in at least Postfix and probably other servers, hence I would suggest this is a function for the MTA, not for the Dovecot relay?
What MTA are you using? If Postfix then there are several off the shelf solutions which control sending rates. As I said in a previous email, I wanted the rate to be configurable per user, and so we store the rates in our user database. It's then fairly trivial to write a small "policy server" to enforce whatever policies you wish, eg as well as rate limiting we have some control over whether users can "forge" their FROM address, etc. This all gets implemented in a small Perl based policy server
Effectively Postfix talks to a network socket for every email, passes a bunch of detail about the email and asks for a yes/no answer. Caveat the boiler plate to listen to a network socket the rest is just a couple of lines of code. Distributed, re-entrant, simple.
Give it some consideration. I doubt the time to implement a complete prototype solution would be more than half a day for your IT guy and if that's attractive then perhaps you have grounds to look at replacing CM?
Good luck
Ed W