Wietse Venema:
> nik600:
> > Virus, botnet and user's bad policies about password allows many 3rd party
> > entities to stole passwords, in the last month i've experienced a grows of
> > hacked users, and in some case many spam messages are sent from my servers
> > before i can block the user.
> >
> > I've tried many combination
> >
> > smtpd_client_message_rate_limit
> > smtpd_client_recipient_rate_limit
> > anvil_rate_time_unit
> >
> > config options but as the sender changes frequently the client, sending
> > from different locations, so the limits above has no effect and i can't
> > stop the spammer.
> >
> > Does exists any configuration to limit the # of sasl login from an user?
> >
> > It could be very useful, and cloud be also useful monitor many login of the
> > same sasl user from different ip.
> >
> > What do you thing about that?
>
> Who has time? Technically it's the same problem as client, message
> and recipient rate limits.
I took a quick look into implementing this, but unfortunately, it
is not as simple as I thought it would be.
Thus, for a quick fix I suggest that you stick with policyd,
postfwd and similar solutions.
What follows are some ideas to improve, generalize and simplify
Postfix's built-in rate limit features.
The existing smtpd_client_*whatever*_limit features are implemented
with counters per SMTP client (specifically, the per-client connection,
starttls, message and recipient rate limits).
What you need is a rate limit per login name. Obviously, that
requires a counter per login name.
It should be easy enough to count per "login name" instead of per
"SMTP client" (after all, those labels are just simple strings that
select a hash-table entry).
However it should not be too easy to exhaust server memory.
In particular, Postfix must not try to maintain huge numbers of
counters when some spammer tries a huge number of different login
names in a short time. Either the use of per "login name" counters
should be restricted to "known" logins, or there should be some
caching mechanism that drops entries when the cache becomes full.
Likewise, rate limits per sender email address or recipient email
address sound attractive, but they should not use up insane amounts
of memory for counters. Again, these counters should be restricted
to "known" addresses, or there should be some caching mechanism
that drops entries when the cache becomes full.
These "new" rate limits would be more usable when they are supported
by a cache that drops entries when full. Supporting this calls for
new Postfix infrastructure: a counter table. I think that memcache
would be a perfect solution for this job: it is memory-resident and
therefore fast, it is designed to work within a finite budget, and
it can be shared between different servers. One just needs to
manage firewalling rules carefully.
A "counter table" implemented on top of memcache would also provide
a way to get rid of the anvil daemon.
Wietse
