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
