[Gross] false positives

[Imri Zvik]

On Wednesday 17 December 2008 19:10:33 Jesse Thompson wrote:
> Imri Zvik wrote:
> > On Wednesday 17 December 2008 14:22:51 Eino Tuominen wrote:
> >> Jesse Thompson wrote:
> >>> You probably need to raise filter_bits setting; especially since you
> >>> are using such a large rotate_interval.
> >>>
> >>> Or, if you use the block_threshold functionality, most messages will be
> >>> blocked and not added to the filters, which reduces the chance of false
> >>> positives.
> >>
> >> Indeed, that's seems to be the best way.
> >>
> >> Just for the record, we are now talking false matches, or collisions in
> >> the bloom filter, not false positives.
> >
> > I forgot to CC the list on my reply to Jesse:
> >
> > If I raise the filter bit, grossd crashes with segmentation fault.
> >
> > Linux greylist2 2.6.9-55.ELsmp #1 SMP Fri Apr 20 16:36:54 EDT 2007 x86_64
> > x86_64 x86_64 GNU/Linux
>
> During the initial filter replication?  We saw a similar problem, but it
> was triggered by Solaris 10 patching.  We were never able to figure out
> the root cause.  Lowering the filter_bits allowed the filters to sync
> before it crashed.
Yes, it crashed a few seconds after startup, while replicating with the other 
perr.

>
> Since you can't raise the filter_bits, can you lower the
> rotate_interval?  That should lower the chance of false matches.

No, as this would require remote MTAs to go through the greylisting process 
more often.

We would like to keep a match for at least a week ~

>
> Jesse


Thank you both for your efforts. I must say that compared to other greylisting 
implementations, yours just fly!