[Rspamd-Users] ratelimit-module behaves differently in rspamd 3.5
Andreas.Simbuerger at Uni-Passau.De
Fri Mar 31 11:03:41 UTC 2023
It can happen that once limited, you cannot send any messages. We observed
it this week with one of our gateways. However this can happen without the
patch as well, if the inbound MTA sends too many recipients in one mail.
This week, we ran into it because the inbound MTA allowed 2000 recipients in one
Mail and our burst limit per user was 240 :-), ooooops. This connection between
max number of recipients and burst always existed, but the invisible factor of
2 will make people unhappy for not easily observable reasons.
Am Friday, dem 31.03.2023 um 11:40 +0100 schrieb Vsevolod Stakhov:
> On 31/03/2023 11:17, Simbürger, Andreas wrote:
> > Hi,
> > rspamd 3.5 introduced a new behavior when checking ratelimit prefixes.
> > Since 3.5 it will consider the messages that will be sent out in the current
> > task as 'pending' messages. This will trigger the ratelimit earlier.
> > In the released 3.5 version exists a small bug in the check lua code that is
> > fixed in master: https://github.com/rspamd/rspamd/pull/4448
> > Here rspamd will factor in the number of recipients of the current task twice,
> > resulting in an even higher burst value for incoming messages.
> > As the leak rate has a lower bound between tries (the burst value is always clamped
> > to 0, if it becomes negative between tasks), you can end up in a situation where
> > you cannot send any new messages, no matter what rate you specified.
> > The fix is pretty easy, if you want to repair it in your deployed installation.
> > Cheers,
> > Andreas
> It is probably worth to include this patch in the stable packages to
> avoid confusion. What do you think?
Zentrum für Informationstechnologie und Medienmanagement
Innstr. 33, 94032 Passau
Telefon: +49 (0)851/509-1851
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6387 bytes
Desc: not available
More information about the Users