Dean Brooks wrote:
> On Tue, Feb 12, 2008 at 08:14:54PM +0000, W B Hacker wrote:
>> Tony Finch wrote:
>>> On Mon, 11 Feb 2008, W B Hacker wrote:
>>>> Tony Finch wrote:
>>>>
>>>>> The major new feature is a mechanism for counting the rate of unique
>>>>> events. The new per_addr option counts the number of different
>>>>> recipients that someone has sent messages to in the last time period.
>>>> What happens if/as/when said 'someone' sends many messages to the *same*
>>>> recipient rather than to different recipients?
>>> They aren't counted, which is the whole point.
>>>
>>> Tony.
>> I understood they were not counted 'there' - but can you clarify as to
>> whether they are / are not counted *anywhere*?
>
> You can accomplish what you are trying to do with the /per_rcpt
> option. s would accumulate a counter of total recipients for whatever
> your key value is.
>
> The /per_addr option is just a new way of only incrementing when
> there is a *unique* destination address. You can still make they
> key anything you want, i.e., tracked by sender IP, sender auth id,
> or even the sender's email address.
>
> On a different note, I think the documentation could probably expand
> upon the importance of choosing a proper key. The key value controls
> how everything is aggregated, and the per_ option controls what is
> counted.
>
> For example, if someone says:
>
> "I want to count number of bad auth attempts from each ip address
> Key = $authenticated_id
> Option = /per_mail
>
> "I want to count number of failed recipients from each email address"
> Key = $sender_address
> Option = /per_rcpt
>
> "I want to count number of unique recipients from any sender"
> Key = ${if !eq{$authenticated_id}{} {$authenticated_id}{$sender_host_address}}
> Option = /per_addr
>
> The other issue that is important is that the keys almost always need
> some sort of prefix to avoid duplicates if you are aggregating different
> things.
>
> The ratelimiting code is very flexible, but you have to wrap your ahead
> around it to really understand what you're doing first.
>
> --
> Dean Brooks
> dean@???
>
Thanks,
I think you've nailed the issue.
The need seems to be primarily for documentation that places more of the
problem-relevant or solution-relevant tools side-by-side in the same
'view-port', even if their ancestry and code-bases came from different
places.
Bill
