Menu
▾
▴
sqlgrey-users
|
From: Max D. <Max...@lr...> - 2005-02-04 15:32:19
|
Hi Lionel, what do You think about the following issues to ease data mining: -> field 'client_name' in connect -> field 'first_seen' in from_awl, domain_awl -> logging (now()-first_seen) within 'too early' - statements in the logfile (easier to grep) -> putting all info concerning a single transaction into one single line instead of two lines (makes it easier to grep) BTW, could You rename connect.ip_addr into host_ip for consistency with from_awl and domain_awl? I understand, that, from a point of view of smart or c-class greylisting, these are different concepts. But from the sql schema point of view I find it rather uncomfortable to use different names for this field. LBNL, hope You enjoyed skiing and returned in good health when You read this (I start my first skiing holiday in my life tonight!) Max |
|
From: Michael S. <Mic...@lr...> - 2005-02-04 16:25:45
|
Hi Lionel, to be a little bit more detailed than Max :-) We just started to use greylisting and the first day shows a reduction of spam by about a factor of 15, that's really great. However, looking around in the logfiles and the mysql database, I am missing some information, to help me see what actually happens. Therefore I would like three additions to the tables in the database. 1. Addition: first_seen Extra field first_seen also for tables form_awl and domain_awl. With this addition you are able to see which new entries have been entered into the database like it is possible now with table connect: select * from connect where first_seen > now() - interval 5 minute; With the from_awl and domain_awl you can only find out which entries have been added OR have been updated. 2. Addition: client_name Extra field client_name in all 3 tables. This would help a human to see from where a connection came. Otherwise, you must always use nslookup or dig to find the name. 3. Addition: usage_count Every update of an entry in from_awl and domain_awl should increment an usage_count. The processing of these fields by sqlgrey should be triggered by configuration options. For people, who do not need the information and do not want to waste storage, they would disable these features. 4. Consistent naming In table connect ip_addr is used whereas host_ip in from_awl and domain_awl. Since it depends on the greylisting mode if the IP address is a full host address or a class C network, you should use ip_addr for all three tables. Now, if you try to find out what information is in every table about an IP address, you can't just change the tablename in the select, but you have to change the fieldname too. Thanks, Michael On Fri, 4 Feb 2005, Max Diehn wrote: > Hi Lionel, > > what do You think about the following issues to ease data mining: > > -> field 'client_name' in connect > -> field 'first_seen' in from_awl, domain_awl > -> logging (now()-first_seen) within 'too early' - statements in the > logfile (easier to grep) > -> putting all info concerning a single transaction into one single line > instead of two lines (makes it easier to grep) > > BTW, could You rename connect.ip_addr into host_ip for consistency with > from_awl and domain_awl? I understand, that, from a point of view of > smart or c-class greylisting, these are different concepts. But from the > sql schema point of view I find it rather uncomfortable to use different > names for this field. > > LBNL, hope You enjoyed skiing and returned in good health when You read > this (I start my first skiing holiday in my life tonight!) > > Max > Michael Storz ------------------------------------------------- Leibniz-Rechenzentrum ! <mailto:St...@lr...> Barer Str. 21 ! Fax: +49 89 2809460 80333 Muenchen, Germany ! Tel: +49 89 289-28840 |
|
From: Lionel B. <lio...@bo...> - 2005-02-04 20:18:57
|
Michael Storz wrote the following on 02/04/05 17:25 : >Hi Lionel, > >to be a little bit more detailed than Max :-) > > > I must admit I had to read Max's mail twice... >We just started to use greylisting and the first day shows a reduction of >spam by about a factor of 15, that's really great. However, looking >around in the logfiles and the mysql database, I am missing some >information, to help me see what actually happens. > >Therefore I would like three additions to the tables in the database. > >1. Addition: first_seen > >Extra field first_seen also for tables form_awl and domain_awl. With this >addition you are able to see which new entries have been entered into >the database like it is possible now with table connect: > >select * from connect where first_seen > now() - interval 5 minute; > >With the from_awl and domain_awl you can only find out which entries have >been added OR have been updated. > > > Seems to be a good thing to have, especially since it will be a small column that shouldn't put much stress on the database. Added to my TODO. >2. Addition: client_name > >Extra field client_name in all 3 tables. This would help a human to see >from where a connection came. Otherwise, you must always use nslookup or >dig to find the name. > > > I'm afraid this won't be so easy : - in the default 'smart' mode, most of the entries aren't IP address but class C networks. - a VARCHAR column with potentially very long names is not a welcomed addition : it could hurt performance badly. >3. Addition: usage_count > >Every update of an entry in from_awl and domain_awl should increment an >usage_count. > > > I like the concept of storing somewhere usage data, but will an usage_count be enough ? For example I'd like to know the top 10 domain_awl entries used last week, but usage_count won't give them to me. I'm wondering if what you need isn't a separate log file parser that would get you various statistics (most frequent spam sources, most used domains, AWL efficiency, ...). The log file should already have everything you need to compute these stats. >The processing of these fields by sqlgrey should be triggered by >configuration options. For people, who do not need the information and do >not want to waste storage, they would disable these features. > >4. Consistent naming > >In table connect ip_addr is used whereas host_ip in from_awl and >domain_awl. Since it depends on the greylisting mode if the IP address is >a full host address or a class C network, you should use ip_addr for all >three tables. Now, if you try to find out what information is in every >table about an IP address, you can't just change the tablename in the >select, but you have to change the fieldname too. > > Agreed. Added to my TODO. Lionel. |
|
From: Michel B. <mi...@bo...> - 2005-02-05 09:10:01
|
Le Vendredi 04 F=E9vrier 2005 21:18, Lionel Bouton a =E9crit : > > Seems to be a good thing to have, especially since it will be a small > column that shouldn't put much stress on the database. Added to my TODO= . > > >2. Addition: client_name > > I'm afraid this won't be so easy : > - in the default 'smart' mode, most of the entries aren't IP address bu= t > class C networks. > - a VARCHAR column with potentially very long names is not a welcomed > addition : it could hurt performance badly. I would vote YES for "first_seen" and "counter" columns in "awl" tables, = and I=20 would vote NO for "client_name". Not only "client_name" would be meaningless for all the class-C records, = but=20 also a reverse DNS entry is something that can change over time. If we pu= t a=20 client_name column, we should update it with the client_name Postfix give= s=20 everytime we update a record. (note that we could very well put there the= =20 last client_name seen even when we use a class-C entry type, as this woul= d=20 still give an indication about the calling client). But I'm not sure that having this in the tables would be very useful. I would also vote YES for having the same field name for the IP in all th= e=20 tables. Adding columns to the tables rises the issue of upgrading : When upgradin= g=20 from an oder version to a version with new columns, should the new column= s be=20 initialized with arbitrary blank/zero or "today" values, or completely dr= op=20 the existing tables and let them rebuild by themselves from scratch with = new,=20 real data ? Regards. --=20 Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E |
|
From: Lionel B. <lio...@bo...> - 2005-02-05 12:50:05
|
Michel Bouissou wrote the following on 02/05/05 10:09 : >Le Vendredi 04 F=E9vrier 2005 21:18, Lionel Bouton a =E9crit : > =20 > >>Seems to be a good thing to have, especially since it will be a small >>column that shouldn't put much stress on the database. Added to my TODO= . >> >> =20 >> >>>2. Addition: client_name >>> =20 >>> >>I'm afraid this won't be so easy : >>- in the default 'smart' mode, most of the entries aren't IP address bu= t >>class C networks. >>- a VARCHAR column with potentially very long names is not a welcomed >>addition : it could hurt performance badly. >> =20 >> > >I would vote YES for "first_seen" and "counter" columns > I see the need for a first_seen : logs are mostly useless for this=20 information. counters : what for ? As I previously said, I'm not sure they will be=20 usefull as logs already hold more relevant information. It will hurt the=20 performance of people willing to use them too (if I make them optionnal=20 as requested) as this will need an update to the database on each and=20 every mail SQLgrey will see (db updates are slow...). If someone tells me what it will be used for that can't be done with a=20 simple log parsing tool, I'd be more inclined to put it in my TODO list.=20 In the other case, I'll add a logparsing tool in the TODO... > in "awl" tables, and I=20 >would vote NO for "client_name". > >Not only "client_name" would be meaningless for all the class-C records,= but=20 >also a reverse DNS entry is something that can change over time. If we p= ut a=20 >client_name column, we should update it with the client_name Postfix giv= es=20 >everytime we update a record. (note that we could very well put there th= e=20 >last client_name seen even when we use a class-C entry type, as this wou= ld=20 >still give an indication about the calling client). >But I'm not sure that having this in the tables would be very useful. > > =20 > Agreed. >I would also vote YES for having the same field name for the IP in all t= he=20 >tables. > >Adding columns to the tables rises the issue of upgrading : When upgradi= ng=20 >from an oder version to a version with new columns, should the new colum= ns be=20 >initialized with arbitrary blank/zero or "today" values, or completely d= rop=20 >the existing tables and let them rebuild by themselves from scratch with= new,=20 >real data ? > > =20 > For first_seen, my plan is to make the update process set them to last_se= en. If counters are really needed, they will be set to 0. Lionel. |
|
From: Michael S. <Mic...@lr...> - 2005-02-05 18:59:53
|
On Sat, 5 Feb 2005, Lionel Bouton wrote: > > I see the need for a first_seen : logs are mostly useless for this > information. Ok, first_seen is the one, I need most. With this field added, I can test new algorithms via cron-job without changing the code of sqlgrey. > > counters : what for ? As I previously said, I'm not sure they will be > usefull as logs already hold more relevant information. It will hurt the > performance of people willing to use them too (if I make them optionnal > as requested) as this will need an update to the database on each and > every mail SQLgrey will see (db updates are slow...). > If someone tells me what it will be used for that can't be done with a > simple log parsing tool, I'd be more inclined to put it in my TODO list. > In the other case, I'll add a logparsing tool in the TODO... > ... > >Not only "client_name" would be meaningless for all the class-C records, but > >also a reverse DNS entry is something that can change over time. If we put a > >client_name column, we should update it with the client_name Postfix gives > >everytime we update a record. (note that we could very well put there the > >last client_name seen even when we use a class-C entry type, as this would > >still give an indication about the calling client). > >But I'm not sure that having this in the tables would be very useful. > > For the fields counter and client_name I must admit that I have no direct use to enhance greylisting at the moment. The reason I want to have these fields is, that I think greylisting as it is implemented at the moment is a sharp sword. But over time spammers will try to circumvent greylisting. My experience over the years showed me that the human brain is very efficient in finding patterns or trying to order chaos. What it needs for this is a lot of information. Digging around in the sql databse with select statements is much easier and faster than writing a log parser. That's the reason why I would like to have these fileds in the database, but as I said before I have no hard facts for inclusion. About performance: I must admit, that I have nearly no knowledge about databases. When I studied computer science long time ago, I somehow managed it to avoid databases. The knowledge I have is about X.500 and ldap. And in these applications there would be no performance loss if you add additional attributes even with big values. The reason is, that this additon will have no influence on the hashing (indexing) of the other attributes. Michael Storz ------------------------------------------------- Leibniz-Rechenzentrum ! <mailto:St...@lr...> Barer Str. 21 ! Fax: +49 89 2809460 80333 Muenchen, Germany ! Tel: +49 89 289-28840 |
|
From: Michel B. <mi...@bo...> - 2005-02-06 09:25:15
|
Le Samedi 05 F=E9vrier 2005 13:49, Lionel Bouton a =E9crit : > > For first_seen, my plan is to make the update process set them to > last_seen. Sounds logical > If counters are really needed, they will be set to 0.=20 "1" would probably be better. If we have an entry in an awl, we have seen= it=20 at least once ;-) --=20 Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E |
|
From: Lionel B. <lio...@bo...> - 2005-02-06 15:14:52
|
Michel Bouissou wrote the following on 02/06/05 10:25 : >Le Samedi 05 F=E9vrier 2005 13:49, Lionel Bouton a =E9crit : > =20 > >>For first_seen, my plan is to make the update process set them to >>last_seen. >> =20 >> > >Sounds logical > > =20 > >>If counters are really needed, they will be set to 0.=20 >> =20 >> > >"1" would probably be better. If we have an entry in an awl, we have see= n it=20 >at least once ;-) > > =20 > I could make that 2 for the domain_awl if the aggregation level is > 1=20 ;-) But I'm not seing counters in the schema yet... |
|
From: Michel B. <mi...@bo...> - 2005-02-05 12:58:24
|
Le Samedi 05 F=E9vrier 2005 13:49, Lionel Bouton a =E9crit : > > counters : what for ? As I previously said, I'm not sure they will be > usefull as logs already hold more relevant information. It will hurt th= e > performance of people willing to use them too (if I make them optionnal > as requested) as this will need an update to the database on each and > every mail SQLgrey will see (db updates are slow...). There's already a database update on each and every mail that SQLgrey see= s :=20 The last_seen entry gets updated. I don't think that updating last_seen + counter would result in any notic= eable=20 performance difference compared to updating last_seen alone... Cheers. --=20 Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E |
|
From: Lionel B. <lio...@bo...> - 2005-02-05 14:07:19
|
Michel Bouissou wrote the following on 02/05/05 13:58 : >Le Samedi 05 F=E9vrier 2005 13:49, Lionel Bouton a =E9crit : > =20 > >>counters : what for ? As I previously said, I'm not sure they will be >>usefull as logs already hold more relevant information. It will hurt th= e >>performance of people willing to use them too (if I make them optionnal >>as requested) as this will need an update to the database on each and >>every mail SQLgrey will see (db updates are slow...). >> =20 >> > >There's already a database update on each and every mail that SQLgrey se= es :=20 >The last_seen entry gets updated. > >I don't think that updating last_seen + counter would result in any noti= ceable=20 >performance difference compared to updating last_seen alone... > =20 > Of course you are right. But the need for counters isn't clear for me yet= ... |
|
From: Michel B. <mi...@bo...> - 2005-02-06 09:24:09
|
Le Samedi 05 F=E9vrier 2005 15:07, Lionel Bouton a =E9crit : > > >I don't think that updating last_seen + counter would result in any > > noticeable performance difference compared to updating last_seen alon= e... > > Of course you are right. But the need for counters isn't clear for me > yet... I would say that IMHO the way to consider the counter is that: 1/ Some people would seem to like it (including me, for non-rational=20 reasons ;-) 2/ It should be a very easy addition 3/ It doesn't hurt performance So... --=20 Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E |
|
From: Lionel B. <lio...@bo...> - 2005-02-06 15:13:37
|
Michel Bouissou wrote the following on 02/06/05 10:24 : >Le Samedi 05 F=E9vrier 2005 15:07, Lionel Bouton a =E9crit : > =20 > >>>I don't think that updating last_seen + counter would result in any >>>noticeable performance difference compared to updating last_seen alone= ... >>> =20 >>> >>Of course you are right. But the need for counters isn't clear for me >>yet... >> =20 >> > >I would say that IMHO the way to consider the counter is that: >1/ Some people would seem to like it (including me, for non-rational=20 >reasons ;-) >2/ It should be a very easy addition >3/ It doesn't hurt performance > >So... > > =20 > Sorry but I need more than that :-) I'm not inclined to add stuff just=20 because it isn't a big deal, especially in the database schema which is=20 the kind of thing I learned to change with caution. Look at the TODO, there are already several things with a clear need... In my opinion a separate log parsing tool would bring far more useful sta= ts. Lionel. |
|
From: Michel B. <mi...@bo...> - 2005-02-07 13:31:33
|
Le Dimanche 06 F=E9vrier 2005 16:13, Lionel Bouton a =E9crit : > > >I would say that IMHO the way to consider the counter is that: > >1/ Some people would seem to like it (including me, for non-rational > >reasons ;-) > >2/ It should be a very easy addition > >3/ It doesn't hurt performance > Sorry but I need more than that :-) Sniff ;-( So what does it take ? ;-) > I'm not inclined to add stuff just because it isn't a big deal, especia= lly > in the database schema which is the kind of thing I learned to change w= ith > caution.=20 Sure, but the database schema will have to change anyway (to include=20 first_seen and rename an IP address field). So it would be the good momen= t to=20 add one more field that costs little. Changing important fields in a data= base=20 schema must be done with caution, I agree, but adding a purely informativ= e=20 field (that won't be used as a key or calculation base or whatever) has n= o=20 consequences... > Look at the TODO, there are already several things with a clear need... Yes. About the todo, a couple of remarks : 1/ I object against integrating SPF in any way in SQLgrey. SPF and greyli= sting=20 are completely different systems, with different goals and approaches. SP= F is=20 implemented in separate patches (I use a Postfix patch) or policy servers= . I=20 don't see the interest of integrating a goat and a cow together ;-) and u= sing=20 SPF to determine whether or not greylisiting should be applied would sure= ly=20 be an easy way for spammers to defeat greylisting... 2/ I still would love to get sender and recipient based whitelisting in=20 SQLgrey. Using Postfix tables for this purpose is not a satisfactory=20 solution, for one can have a whole series of tests in Postfix, and differ= ent=20 exceptions for each kind of test. One may want to skip greylisting for so= me=20 sender (i.e. somebody@somedomain), but for example still want to perform = SPF=20 tests on somedomain. Using a Postfix table with "somebody@somedomain =3D>= OK"=20 would cause *all* subsequent tests to be skipped for this message, not on= ly=20 greylisting. And it makes it a headache in ordering tests if using differ= ent=20 Postfix tables for this... It would sound logical and easier to me that each "policy server" embarks= its=20 own independent whitelisting for conditions under which this given test=20 should be performed or not... > In my opinion a separate log parsing tool would bring far more useful > stats. Sure, a log parsing tool is most useful, and probably most mail admins ha= ve=20 something like this. But a counter gives *different* information that can= be=20 seen in the databaseat a glimpse, i.e. "is this sender an usual, frequent= =20 correspondent, or did he send only once" ? (as some spammers or viruses d= o,=20 and yes, sometimes, they can pass thru greylisting)... The counter would allow, for example, to easily extract the ratio of send= er=20 that have been seen only once compared to the ratio of "repeating" sender= s=20 present in the database. For analyzing the database, this is useful (and = easy=20 to get), and a log parsing tool won't give this information. Cheers. --=20 Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E L=E0 o=F9 il n'y a pas de r=E9ponse, il n'y a pas de question. |
|
From: Lionel B. <lio...@bo...> - 2005-02-07 14:20:45
|
Michel Bouissou wrote the following on 02/07/2005 02:31 PM : >Le Dimanche 06 F=E9vrier 2005 16:13, Lionel Bouton a =E9crit : > =20 > >>I'm not inclined to add stuff just because it isn't a big deal, especia= lly >>in the database schema which is the kind of thing I learned to change w= ith >>caution.=20 >> =20 >> > >Sure, but the database schema will have to change anyway (to include=20 >first_seen and rename an IP address field). So it would be the good mome= nt to=20 >add one more field that costs little. Changing important fields in a dat= abase=20 >schema must be done with caution, I agree, but adding a purely informati= ve=20 >field (that won't be used as a key or calculation base or whatever) has = no=20 >consequences... > > =20 > This makes sense to me. But there are so many purely informative fields.=20 For example it just occured to me that you *may* want to have a=20 "previously_seen" field in order to do queries like that : SELECT sender_domain, host_ip, last_seen - previously_seen FROM=20 domain_awl ORDER BY (last_seen - previously_seen) LIMIT 50; I'd even argue that this will be more useful than a counter field... but=20 still less useful than a log parsing tool. >>Look at the TODO, there are already several things with a clear need... >> =20 >> > >Yes. About the todo, a couple of remarks : > >1/ I object against integrating SPF in any way in SQLgrey. SPF and greyl= isting=20 >are completely different systems, with different goals and approaches. S= PF is=20 >implemented in separate patches (I use a Postfix patch) or policy server= s. I=20 >don't see the interest of integrating a goat and a cow together ;-) and = using=20 >SPF to determine whether or not greylisiting should be applied would sur= ely=20 >be an easy way for spammers to defeat greylisting... > =20 > It may be, this entry is only a reminder for me. I know for sure that=20 blindly trusting SPF is a no-no, the "experiment" only means that I'm=20 wondering if SQLgrey rejecting SPF invalid senders instead of=20 greylisting them may be useful (the question is merely to find out if=20 there's a point combining both informations outside Postfix in the=20 policy server or not) or if relying on a separate policy server is the=20 way to go (and document this in the HOWTO). Don't pay too much attention=20 to this TODO entry. >2/ I still would love to get sender and recipient based whitelisting in=20 >SQLgrey. Using Postfix tables for this purpose is not a satisfactory=20 >solution, for one can have a whole series of tests in Postfix, and diffe= rent=20 >exceptions for each kind of test. One may want to skip greylisting for s= ome=20 >sender (i.e. somebody@somedomain), but for example still want to perform= SPF=20 >tests on somedomain. Using a Postfix table with "somebody@somedomain =3D= > OK"=20 >would cause *all* subsequent tests to be skipped for this message, not o= nly=20 >greylisting. And it makes it a headache in ordering tests if using diffe= rent=20 >Postfix tables for this... > =20 > I don't find test ordering in Postfix the most intuitive thing either :-) >It would sound logical and easier to me that each "policy server" embark= s its=20 >own independent whitelisting for conditions under which this given test=20 >should be performed or not... > > =20 > For recipients I'm more than OK with it (this is the opt-in and opt-out=20 TODO entry). For senders, as I already said, I see it as a big hole in the=20 greylisting process. > =20 > >>In my opinion a separate log parsing tool would bring far more useful >>stats. >> =20 >> > >Sure, a log parsing tool is most useful, and probably most mail admins h= ave=20 >something like this. But a counter gives *different* information that ca= n be=20 >seen in the databaseat a glimpse, i.e. "is this sender an usual, frequen= t=20 >correspondent, or did he send only once" ? (as some spammers or viruses = do,=20 >and yes, sometimes, they can pass thru greylisting)... > >The counter would allow, for example, to easily extract the ratio of sen= der=20 >that have been seen only once compared to the ratio of "repeating" sende= rs=20 >present in the database. For analyzing the database, this is useful (and= easy=20 >to get), and a log parsing tool won't give this information. > =20 > Now, that's more an argument I can understand for storing this=20 information. But won't someone prefer a "previously_seen" (which by the=20 way is slightly more complex to implement) ? If the entry can't be found=20 more than once in the logs covering the awl ttl period, you'll have=20 nearly the same information... Lionel. |
|
From: Michel B. <mi...@bo...> - 2005-02-07 15:28:54
|
Le Lundi 07 F=E9vrier 2005 15:20, Lionel Bouton a =E9crit : > > >The counter would allow, for example, to easily extract the ratio of > > sender that have been seen only once compared to the ratio of "repeat= ing" > > senders present in the database. For analyzing the database, this is > > useful (and easy to get), and a log parsing tool won't give this > > information. > > Now, that's more an argument I can understand for storing this > information. But won't someone prefer a "previously_seen" Not for me, thanks ;-) --=20 Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E |
|
From: Michel B. <mi...@bo...> - 2005-02-07 15:43:05
|
Le Lundi 07 F=E9vrier 2005 15:20, Lionel Bouton a =E9crit : > 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. 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 mana= ge=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 and= =20 most of DJB's production ;-) 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... But that's not technique anymore, that's philosophy ;-)) --=20 Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E |
|
From: Lionel B. <lio...@bo...> - 2005-02-07 17:42:33
|
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. |
|
From: Michel B. <mi...@bo...> - 2005-02-07 18:09:22
|
Le Lundi 07 F=E9vrier 2005 18:42, Lionel Bouton a =E9crit : > > You hit below the belt :-) Sorry :-} > At least I did release SQLgrey under the GPL=20 And for sure everybody here duly appreciate this ! > Resistance to new features is a very important part of project > management. That's right. > (but patches are welcomed...). If I were a decent Perl coder, surely I would code myself what I need and= =20 submit the patches. Unfortunately I'm not. But I may take a look at it=20 someday ;-) Cheers. --=20 Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X