Re: [Sqlgrey-users] Re: Sender whitelisting

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

Michel Bouissou wrote the following on 02/07/2005 04:42 PM :

>Le Lundi 07 F=E9vrier 2005 15:20, Lionel Bouton a =E9crit :
> =20
>
>>For recipients I'm more than OK with it (this is the opt-in and opt-out
>>TODO entry).
>>For senders, as I already said, I see it as a big hole in the
>>greylisting process.
>>   =20
>>
>
>If the default is to come with an empty sender whitelist, IMHO it doesn'=
t=20
>"open a hole", but it gives "flexibility to the user" as it lets him man=
age=20
>the tool he uses according to his own needs and specific server=20
>configuration.
>
>The default empty sender whitelist can even come with all the necessary=20
>warnings stating that using it is a bad idea ;-))
>
>It's commonplace to say that most of the times developpers of tools don'=
t have=20
>exactly the same needs and views about the tools they develop, than some=
=20
>users may have among a broad userbase.
>
>Now the philosophical debate is about whether a developper's goal should=
 be to=20
>keep the tool fitting exactly to his own personal view (you get qmail an=
d=20
>most of DJB's production ;-)
>

You hit below the belt :-) At least I did release SQLgrey under the GPL=20
(in fact I had no choice, although there isn't much code left from it,=20
SQLgrey is a postgrey fork). Someone else can fork SQLgrey itself and=20
not have to look behind (managing lists of patches like the ones for=20
djbdns).

That said, my reluctance to add some things to SQLgrey is based on=20
different things :
- usefulness to the users,
- impact on the code complexity and performance,
- time needed to code.

For example, you were quite close to convince me to add the counter in=20
one previous mail by presenting a use case. My problem with it is only=20
that I think this data won't be meaningful enough, when you start to=20
make stats, you want more than a simple counter.


> or if the developper should try to bring=20
>features that his users would like to see as long as they are not=20
>incompatible with the tool...
>
> =20
>

Resistance to new features is a very important part of project=20
management. For the counter, it didn't yet pass the "usefulness" test=20
for the reasons I gave. For the sender whitelists, it's not that far,=20
presented like you did (with a default conf file with appropriate=20
warnings) I'm not really against it. It's not on the top of my list=20
though (but patches are welcomed...).

Best regards,

Lionel.