Re: [exim] Rate limiting: /strict and /leaky

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Tony Finch
Datum:  
To: Brian Candler
CC: exim-users
Betreff: Re: [exim] Rate limiting: /strict and /leaky
On Thu, 22 Sep 2005, Brian Candler wrote:
>
> If they send a burst of 10,000 mails then the first 10 will get through, and
> the remaining 9,990 will be rejected. However, is it true that it will also
> take ~999 hours before they are allowed to send any more mail, even if they
> make no further attempts in the mean time?


The time period set by you is the time it takes for the measured rate to
decay to 1/e of its current value. So,
    10 = 10000*exp(-t)
    t = -ln(10/10000) = 6.9 periods
Exponentials increase very fast, so it would be really quite hard to make
the recovery time unfeasibly big.


> With /leaky, some mail will get through. e.g. if you continuously hit
> formmail many times per minute, then still over an hour 10 mails will get
> through. That's not ideal because an abuser hitting a formmail script hard
> will still be able to get *some* benefit.


Ratelimiting is only part of an email security policy. You can't expect it
to solve all your problems. I implemented the feature to help me mitigate
the worst effects of a spam-related security incident - a few hundred junk
messages isn't likely to get us blacklisted in the way that 45,000 will,
and log monitoring will alert us so we can fix the problem before a few
hundred becomes a few thousand.

> I guess what I'd really like is something in between, which results in:
> - if a continuous attack is in progress, then no mail at all gets through
> - once the attack has stopped, then mail can flow again, without having
> been excessively penalised for the number of failed attempts during the
> attack


If you set a short time interval then the time to recovery is short.

> One way might be to 'clip' the number of mail sending attempts recorded in
> the ratelimit database, e.g. if message limit L per period P then always
> update the value in the database as strict does, but clip it to (say) 1.1L
> or 2L. An attack will keep the value topped up above L, but it can quickly
> recover afterwards.


I'm not sure if that's actually useful, given the flexibility available
from the smoothing period.

> However, it would also be nice for exim_dumpdb to show the actual rate
> values while an attack is in progress, as /strict does now.


    warn    ratelimit = M / P / strict
    defer    ratelimit = M / P / leaky


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}}