On Thu, Nov 02, 2006 at 03:03:15PM -0800, Marc Perkel wrote:
> So - what you are saying is that if I do an ACL where I have a ratelimit
> and there is another condition that fails then the ratelimit won't be
> counted and I can extract the ratelimit info to a variable that I can
> use in the next ACL?
Actually, it's funny you brought this up Marc, because I ran into a
similar (but slightly different) issue for which I patched in a custom
${ratelimit:key} variable to extract the stored value of a ratelimit key.
There's no problem, as others noted, in storing the ratelimit value
in a variable for future ACL use for the same message.
However, imagine a scenario where you want to increment a ratelimit
counter every time a host issues a RCPT-TO to an invalid user, and
then you want to test during a *future* connection whether they have
exceeded this value to deny them access. You can't do it because
testing has the unwanted side effect of incrementing the counter,
which will cause inaccurate counts.
Ultimately, I stopped using the ${ratelimit:xxx} patch because
managing the keys was a mess. Apparantely the built-in ratelimiting
code currently stores whitespace into the ratelimit key, so if your
lookup key doesn't exactly match you won't get the right values.
Maybe someday I'll get around to fixing the original code to not do that.
> Would be nice, if Phil is listening - new feature - to have some kind of
> a "no-count" option so a count can be tested without counting it.
Agreed. It would essentially eliminate the need for external storage
for a significant amount of counters. Right now, you cannot actually
test an existing stored value without also incrementing at least once.
