[Gross] false positives
imriz at bsd.org.il
Thu Dec 18 09:29:40 EET 2008
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
> 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
We would like to keep a match for at least a week ~
Thank you both for your efforts. I must say that compared to other greylisting
implementations, yours just fly!
More information about the Gross