Milter-greylist

On 18/07/2008, shuttlebox <shuttlebox@...> wrote:
> On Fri, Jul 18, 2008 at 6:09 PM, Constantine A. Murenin
>  <mureninc@...> wrote:
>  > * My current understanding, not explicitly supported by
>  > greylist.conf(5), is that with milter-greylist this 'timeout' value
>  > corresponds to the period of time that the greylisting tuples are
>  > stored after the greylist time is already over, e.g. if you have
>  > 'greylist 1h' and 'timeout 4h', then the total time the brute force
>  > tuples are stored before being ejected is 5h, not 4 hours as it would
>  > have been with the suggested timeout terminology from the original
>  > whitepaper and some other greylisting implementations.
>
>
> That can't be right but I vaguely remember that the actual cleansing
>  of the database is done not directly at timeout but following some
>  other algorithm, probably when there's a number of tuples to remove.
>  Maybe that's why you think it's the sum of those times or because the
>  actual database is in memory, the disk copy is just that - a copy
>  dumped periodically so that file can contain tuples no longer in
>  memory.

My reasoning is based on the fact that milter-greylist tuple contains
a timestamp when such a greylisted tuple can become an autowhitelisted
tuple, as opposed to a timestamp when such a tuple was first seen.

As you know, global 'greylist' time could be adjusted in local rules
via the 'delay' keyword, thus you'd need to know the exact rule which
has generated a tuple before you could re-create it's creation time
(if you want to apply the 'timeout' time the way it is done in some
other implementations and Evan's whitepaper, which store the
first-seen timestamp).

C.