[Rspamd-Users] What's the deal with multiple buckets at the rate limit?

[Simbürger, Andreas]

Hi,

your buckets need a 'prefix', usually created by using the selectors as
described in the documentation.
Ratelimits are tracked per prefix (=bucket). Depending on your selector
configuration, you can create interactions or completly different behavior.

When rspamd checks the ratelimit (as a pre-filter, if not configured otherwise),
it will check all prefixes sequentially. If one prefix has set the pre-result (soft reject),
it will reject the mail afterwards. All prefixes will beck checked, regardless of
an existing pre-result from a previous prefix.

So in your example, if you have 2 different selector strings, the one that triggers
first determines the time when soft rejects occur.
If you create the same prefix for them, the smallest burst will trigger it first,
and the higher rate will lead to a "faster unlock" of the bucket. So, effectively
you get the "union" of both buckets: min(burst) and max(rate).

Cheers,
Andreas


Am Wednesday, dem 29.03.2023 um 07:52 +0000 schrieb Daniel, Sebastian:
> Hello,
> 
> It is about the Ratelimit module:
> how may I understand the use of multiple buckets?
> 
> As an example:
> 
> rates {
>    user = {
>      bucket = [
>      {
>        burst = 100;
>        rate = "10 / 1min"
>      },
>      {
>        burst = 10;
>        rate = "100 / 1min";
>      }]
>    }
> }
> 
> Would this mean that the buckets are symbolically parallel or one above the other in the row as listed?
> 
> If in row:
> Would that mean the first one holds 100 and lets 10 more through every minute into the second one, which can only hold
> 10, but lets them through much faster (100 per minute)?
> 
> If Parallel:
> Would that mean that the second one defunds the first one a bit when it is full?
> That is, if the first is "full" and blocks, then the second can mitigate this a little, because it has a much higher
> rate?
> 
> And what is the purpose of the expiry of a bucket?
> What I can see in the redis, the key of a bucket is never reset (p), but only the burst value (b).
> Can someone explain these two values (p and b), that is, how they affect each other?
> 
> As I understand it, the bucket in the redis remains full (p) (pending messages) and only the leak rate in connection
> with the elapsed time determines what it lets through (b).
> So that at some point the bucket is completely "empty" again, it must be regenerated (expiry).
> But why is the b-value reduced? and sometimes not?
> 
> Or have I completely misunderstood the behavior?

-- 
Andreas Simbürger
IT-Sicherheitsberater
Zentrum für Informationstechnologie und Medienmanagement

Universität Passau
Innstr. 33, 94032 Passau
Telefon: +49 (0)851/509-1851
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6387 bytes
Desc: not available
URL: <https://lists.rspamd.com/pipermail/users/attachments/20230331/69d46cae/attachment.bin>