Re: [exim] Ratelimit Tricks

Dean Brooks wrote:
> On Fri, Nov 10, 2006 at 11:38:18AM -0500, Eli wrote:
>
>> Are you sure? After reading what the per_cmd option does for ratelimit, it
>> sounds as if you merely need to have it after a condition that will pass
>> when you want it to, and fail otherwise (in which case the ratelimit command
>> will never be processed).
>
> If you are just trying to do a simple check to see if someone is over
> a limit, there is no way to check a ratelimit value without incrementing
> at least once.
>
> Imagine ratelimiting a sender ip that sends to too many invalid recipients.
>
> At some point in the transaction, you need to check the current ratelimit
> value without incrementing (since you still want to check the ratelimit
> value even if they are sending to a valid recipient). There is no way
> that I am aware of to do this.
>
> --
> Dean Brooks
> dean@???
>

Doesn't look overly daunting to add a 'readonly' feature to the source code and
recompile.

But I still can't get my own arms around *why* it is seen to be needed.

A walk thru the code indicates ratelimit is moderately complex, yet was
implemented with minimal fuss, will JFDI, and works fine 'out of the box' for us
using the example shown in the spec.

If we want to play head games with a spambot (generally a waste of time and
ergs) smacking it with a heavier instrument seems more appropriate than a pinprick.

Shifting the bugger to singleton recipients, 3 or fewer connections per IP, and
progressive delays, for 'dodgy' arrivals, for example.

That said, a simple 'drop' on first invalid recipient is cheap and cheerful.

They may not get tired, but neither do we.

Bill