Re: [Sqlgrey-users] warn_if_reject to populate the db

[Lionel B. <lio...@bo...>]

Michel Bouissou wrote the following on 28.06.2005 17:25 :

>Le Mardi 28 Juin 2005 17:09, Michael Storz a =E9crit :
> =20
>
>>These algorithms run for about 4 months at our site and they have prove=
n
>>to be very successful.
>>   =20
>>
>
>I have no doubt about it. But to me the question is about the vocation o=
f=20
>SQLgrey. Is SQLgrey supposed to be a (very efficient) greylisting system=
, or=20
>is it evoluating to become an exhaustive MTA anti-spam policy server=20
>implementing each and every possible way of filtering spam (before queue=
)..
>
> =20
>

SQLgrey already does more than pure greylisting. It uses a specific
whitelist and AWLs, 1.7.x even does throttling. Whatever will be added
to SQLgrey will try to help fine-tune the greylisting process more or
less in the same way:
- either try to avoid greylisting "know good" clients as is done today,
- maybe discriminate among senders, enforcing different reconnect delay
or reconnect tries before they enter AWLs and/or are allowed to pass.

The keyword here is *combination*: if we can combine other informations
about the connection to help fine-tune the greylisting process *and* it
is impossible to do with Postfix alone or really difficult (Michel, I
don't want to awaken another thread but you are the one asking for "MAIL
FROM:" whitelists in SQLgrey although it is rather easy to use them with
Postfix, your position here surprises me...) then adding code to SQLgrey
makes sense (especially when SQLgrey will be modular).

Lionel.