search

felix / gross

Greylisting of suspicious source (exported from code.google.com/p/gross)
Other
5 stars 0 forks source link

don't update database if multiple checks match #42

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Here is an idea for new configurable option:

grey_update_max = int 

where the database will not update if more than grey_update_max checks match

this will give these senders a perpetual temp block, which is effectively
the same as a perm block, without too much of a code redesign.

it would require that check short-cutting would have to be disabled

Original issue reported on code.google.com by jesserth...@gmail.com on 24 Jan 2007 at 5:13

GoogleCodeExporter commented 9 years ago 
How about this kind of a logic?

There would be two kind of checks, normal and definitive. Normal checks can 
return UNDEFINED or 
SUSPICOUS responses, and definitive checks can return the same two plus BLOCK 
or PASS. Priority order from 
most to least significant would be PASS, BLOCK, SUSPICIOUS, UNDEFINED. Then, 
grossd could short cut

IF all the definitive checks have returned AND
there is at least one SUSPICIOUS response.

Or, if block_threshold (or whatever) is set

IF all the definitive checks have returned AND (
         there is at least block_threshold SUSPICIOUS responses OR
         number of SUSPICIOUS responses + checks_running < block_threshold
)

This change also requires more internal modifications as the reason string must 
be transferred from the check 
to the client and formatted according the client protocol.

Comments?

Original comment by eino.tuominen@gmail.com on 1 Feb 2007 at 6:54

GoogleCodeExporter commented 9 years ago 
It looks like a good plan.

You can also shortcut if a PASS comes in, even if there are some definitive 
checks
that haven't returned.

Do you not like the idea of issuing a perpetual temp block (give a grey response
without updating the database) instead of issuing a perm block?  This might 
save some
coding.  Plus it gives legitimate senders a few days (normally) to de-list 
before
mail starts bouncing.

Original comment by jesserth...@gmail.com on 2 Feb 2007 at 2:35

GoogleCodeExporter commented 9 years ago 
> Tou can also shortcut if a PASS comes in, even if there are some definitive 
checks
> that haven't returned.

Good, that's true.

> Do you not like the idea of issuing a perpetual temp block...

I can implement that, too.  But, IMO it's more polite to tell at once if there 
is a chance you are not going to 
accept the mail at all. That way a legitimate sender will know there is a 
problem and can take other measures 
to contact the recipient.

Btw, the check_dnsbl can be modified to have a configurable option to make it a 
definitive check and return a 
BLOCK response if threre is at least dnsbl_block_threshold matches from the 
lists.

Original comment by eino.tuominen@gmail.com on 2 Feb 2007 at 4:05

GoogleCodeExporter commented 9 years ago

Original comment by eino.tuominen@gmail.com on 7 Apr 2008 at 4:43