On Thu, 1 Jun 2006, Patrick von der Hagen wrote:
> Jeremy Harris schrieb:
> >
> > Um, exim has had rate-tracking in ACLs for ages.
>
> Hmmm, if I'm not mistaken ages=="since February", when exim 4.60 was
> released? ;-)
I committed it near the start of May last year and it was included in the
version 4.52 which was released that July.
> However, the key is "average of mails/timeunit .... significant
> derivation". I don't want to have fixed limits but consider keeping
> several values for a given IP, like average values, maximum values, etc.
> and them do some calculations wheter the current rate "seems to be
> strange". Some kind of "self-learning-method", automatically calculating
> the limits when to take action.
My todo list includes some work on the ratelimit code to allow read-only
access to the ratelimit database, which would allow you to limit a
sender's short-term rate to some factor of their long-term average, for
example. It might be worth adding support for measuring peak rates and
perhaps the rate variance, which would both be quite cheap to compute.
More complicated stats would probably require significant data storage
or log processing, which isn't really appropriate in an ACL :-)
But in general, you will find that client behaviour is very unpredictable
and bursty, so there is a limit to what rate-limiting can achieve.
> Perhaps it would pay-off to have different limits for a sender,
> depending on time, day of week, etc.
You can already do that, because the limit is a string expansion that can
be a lookup keyed on anything you like.
Tony.
--
<fanf@???> <dot@???>
http://dotat.at/ ${sg{\N${sg{\
N\}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}\
\N}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}
