[Sqlgrey-users] Is sqlgrey dead?

[s***@xemaps.com]

Just curious, but there has been no updates since August 5, 2007 in which the last version, 1.7.6 (devel) was released. I currently use this version on my production server and it works just fine. So is this a if it isn't broken don't fix it scenario, or has development just halted?

Thanks, Andrew

[Craig White]

Post by s***@xemaps.com
Just curious, but there has been no updates since August 5, 2007 in which the last version, 1.7.6 (devel) was released. I currently use this version on my production server and it works just fine. So is this a if it isn't broken don't fix it scenario, or has development just halted?

----
Lionel has stopped developing it but it seems to work well.

I see him on the rubyonrails list so I know he's around but probably not
doing so much perl these days.

I vaguely recollect him offering to have someone else assume the
project.

Craig

[Lionel Bouton]

Post by Craig White

Post by s***@xemaps.com
Just curious, but there has been no updates since August 5, 2007 in which the last version, 1.7.6 (devel) was released. I currently use this version on my production server and it works just fine. So is this a if it isn't broken don't fix it scenario, or has development just halted?

----
Lionel has stopped developing it but it seems to work well.
I see him on the rubyonrails list so I know he's around but probably not
doing so much perl these days.

Only when it's more convenient to do so.

I've hit a small bug in a corner case recently (a crash on repeated
database failures in some cases) so I might push a new release one day
but don't hold your breath for it.
I'm currently managing 2 small companies, they take quite a bit of my
time...

Lionel

[Dan Faerch]

Post by s***@xemaps.com
Just curious, but there has been no updates since August 5, 2007 in which the last version, 1.7.6 (devel) was released.

The 1.7.5 and 1.7.6 was released by me, to add a bunch of new features.
1.7.5 added my new features and 1.7.6 fixed whatever bugs i had in my code.

I think Lionel wanted to see the devel version work for a good while,
before flagging it as "stable", but never got around to it :).. I forgot
about it as well, as "it just worked" for me. And this mailinglist got
all quiet, which usually means "everything is fine".

I think we can call it stable by now ;) I run it under very heavy load
in a 10 server cluster. No problems.

Post by s***@xemaps.com
I currently use this version on my production server and it works just fine. So is this a if it isn't broken don't fix it scenario, or has development just halted?

It just works fine i guess.. Theres really nothing more to add at the
moment :).

- Dan

[s***@xemaps.com]

* Replies will be sent through Spamex to
http://www.spamex.com/i/?v=25917804

Post by s***@xemaps.com
Just curious, but there has been no updates since August 5, 2007 in which
the last version, 1.7.6 (devel) was released.

The 1.7.5 and 1.7.6 was released by me, to add a bunch of new features.
1.7.5 added my new features and 1.7.6 fixed whatever bugs i had in my code.
I think Lionel wanted to see the devel version work for a good while,
before flagging it as "stable", but never got around to it :).. I forgot
about it as well, as "it just worked" for me. And this mailinglist got
all quiet, which usually means "everything is fine".
I think we can call it stable by now ;) I run it under very heavy load
in a 10 server cluster. No problems.

Post by s***@xemaps.com
I currently use this version on my production server and it works just
fine. So is this a if it isn't broken don't fix it scenario, or has
development just halted?

It just works fine i guess.. Theres really nothing more to add at the
moment :).
- Dan
---------------------------------------------------------------------------
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Sqlgrey-users mailing list
https://lists.sourceforge.net/lists/listinfo/sqlgrey-users

Well, I guess that answers my question. I am glad there are still developers
still around. Between greylisting and spamhaus (SBL) checking, spam is cut
down by probably 90%. I can't really complain ;). I actually do have one
question, but I'll post that in a separate email.

Thanks!

[Michal Ludvig]

Post by Dan Faerch

Post by s***@xemaps.com
I currently use this version on my production server and it works
just fine. So is this a if it isn't broken don't fix it scenario,
or has development just halted?

It just works fine i guess.. Theres really nothing more to add at the
moment :).

Well there is one thing - IPv6 handling is still a problem. I posted a
problem description and a patch about a year ago and it still doesn't
seem to be integrated:
http://osdir.com/ml/mail.postfix.sqlgrey/2008-05/msg00000.html
http://osdir.com/ml/mail.postfix.sqlgrey/2008-05/msg00001.html

Could you consider applying it to the CVS please?

Thanks

Michal

[Michal Ludvig]

Post by Michal Ludvig

Post by Dan Faerch
It just works fine i guess.. Theres really nothing more to add at the
moment :).

Well there is one thing - IPv6 handling is still a problem. I posted a
problem description and a patch about a year ago and it still doesn't
http://osdir.com/ml/mail.postfix.sqlgrey/2008-05/msg00000.html
http://osdir.com/ml/mail.postfix.sqlgrey/2008-05/msg00001.html

FYI the database schema is already prepared for IPv6 so there is no need
to change that. The above mentioned patch is all that it takes to
correctly support IPv6.

Michal

[Dan Faerch]

Post by Michal Ludvig
Well there is one thing - IPv6 handling is still a problem. I posted a
problem description and a patch about a year ago and it still doesn't
http://osdir.com/ml/mail.postfix.sqlgrey/2008-05/msg00000.html
http://osdir.com/ml/mail.postfix.sqlgrey/2008-05/msg00001.html
Could you consider applying it to the CVS please?

I cant check the patch, since im not "IPv6 ready" yet. I have no servers
running ipv6 and nor experience with it.

Yet, valid IPv6 support definitely sounds like a must.
Your explanation in the email seems reasonable and the code looks nice
and clean.

I no one objects, ill add it to CVS within the next couple of days.


- <http://blog.hacker.dk/> Dan Faerch

[Karl O. Pinc]

Post by Dan Faerch

Post by Michal Ludvig
Well there is one thing - IPv6 handling is still a problem.

I cant check the patch, since im not "IPv6 ready" yet. I have no
servers running ipv6 and nor experience with it.
I no one objects, ill add it to CVS within the next couple of days.

It can't be any more broken than it is now. ;-)

Karl <***@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein

P.S. It's good to see someone's minding the store.

[Patrick Vande Walle]

Post by Karl O. Pinc

Post by Dan Faerch

Post by Michal Ludvig
Well there is one thing - IPv6 handling is still a problem.

I cant check the patch, since im not "IPv6 ready" yet. I have no
servers running ipv6 and nor experience with it.
I no one objects, ill add it to CVS within the next couple of days.

It can't be any more broken than it is now. ;-)

Indeed. This is why I use the IPv6 code included in this fork:
http://apthorpe.cynistar.net/code/sqlgrey/

It is based on the Net::CIDR module, which makes parsing IPv4 and IPv6
addresses much more reliable and easy.

I receive quite a lot of e-mail delivered over IPv6 and can testify it
works fine.

[Bob Apthorpe]

Hi,

Post by Patrick Vande Walle

Post by Karl O. Pinc

Post by Dan Faerch

Post by Michal Ludvig
Well there is one thing - IPv6 handling is still a problem.

I cant check the patch, since im not "IPv6 ready" yet. I have no
servers running ipv6 and nor experience with it.
I no one objects, ill add it to CVS within the next couple of days.

It can't be any more broken than it is now. ;-)

http://apthorpe.cynistar.net/code/sqlgrey/
It is based on the Net::CIDR module, which makes parsing IPv4 and
IPv6 addresses much more reliable and easy.
I receive quite a lot of e-mail delivered over IPv6 and can testify
it works fine.

Wow - I had no idea anyone was using that; it's less of a fork than just
a reformat and refactoring with perltidy, perlcritic, etc. My guess is
that I added Net::CIDR because I knew someone else had solved the
netblock decipherment issue and I'm all about fobbing code maintenance
off on others ;)

I'm not actively using sqlgrey but I'm willing to revisit my version and
help port useful features into the official (and maintained) version of
the code.

Anymore I'm pretty religious about using perltidy & perlcritic but not
out of slavish adherence to dogma. It's mostly because I'm too lazy to
pay attention to coding style and formatting. This way I can just hack,
fix the perlcritic warnings, and filter the code through perltidy so it
looks sane & standardized. If people don't like it, they can argue with
Damian Conway :)

-- Bob

[Dan Faerch]

Post by Bob Apthorpe

Post by Patrick Vande Walle
http://apthorpe.cynistar.net/code/sqlgrey/

I didnt even know there was a fork :).

Post by Bob Apthorpe
that I added Net::CIDR because I knew someone else had solved the
netblock decipherment issue and I'm all about fobbing code maintenance
off on others ;)

Net::CIDR is definitely also a possibility and is probably a more widely
tested solution.

Post by Bob Apthorpe
I'm not actively using sqlgrey but I'm willing to revisit my version and
help port useful features into the official (and maintained) version of
the code.

Did you add other features, besides the Net::CIDR stuff? Then drop us a
list, so each suggested addition can be discussed here. Usually
everybody here has an opinion :). (which is good).
Patches should be made against current CVS version. (not a perl-tidy'et
version ;)). If the patches are small and simple, its way easier to get
me to add them. (because a major restructuring of the code would take me
forever to verify and.. Well.. Yes i am that lazy ;)).

Regards.
- Dan Faerch

[Bob Apthorpe]

Hi,

Post by Dan Faerch
Did you add other features, besides the Net::CIDR stuff? Then drop us a
list, so each suggested addition can be discussed here. Usually
everybody here has an opinion :). (which is good).

Honestly, I don't recall. If timestamps are to be believed, I last
messed with the code in late 2006.

Post by Dan Faerch
Patches should be made against current CVS version. (not a perl-tidy'et
version ;)). If the patches are small and simple, its way easier to get
me to add them. (because a major restructuring of the code would take me
forever to verify and.. Well.. Yes i am that lazy ;)).

Yeah, that was sort of the problem. I tidied the code so I could
understand it well enough to refactor it. By doing so, I made it
impossible to diff in order to submit a patch. It's sad that a little
white space can screw one over so badly, but that's life. So I posted my
mangled version of the code so the changes were available, if not
integrated with the canonical source.

If the Net::CIDR addition is vital, I'll see what I can extract from my
hack and incorporate into the current non-tidied CVS version of sqlgrey
(the changes look small.) No point in letting the work go to waste, even
if I don't remember any of it :)

Also, FWIW, I used a tiny bit of eval() trickery to check if Net::CIDR
was available (also checked for Time::HiRes and Sys::Hostname the same
way.) I used Net::CIDR if it was there, otherwise I stuck with the
existing code to avoid screwing people who upgraded without knowing that
dependencies had changed.

My big picture goal was to split the code into a small driver script and
a module (potentially Mail::Postfix::Policy::Sqlgrey, inheriting from
Net::Server::Multiplex.) IIRC, the big sticking point involved a
self-reference passed to signal handlers in pre_loop_hook(). My OO-fu
was not sufficient for sorting out how to resolve that scoping issue.

-- Bob

[Michal Ludvig]

Post by Bob Apthorpe
I used Net::CIDR if it was there, otherwise I stuck with the
existing code

Aha. In that case the non-Net::CIDR implementation of IPv6 handling
should be fixed anyway, shouldn't it ;-)

And once everything works without Net::CIDR there's little point adding
a dependency on another nonstandard module. Unless it brings features
not available otherwise of course.

So -- what do we get from Net::CIDR that we can't have without? The
point is that sqlgrey shouldn't have unneeded dependencies that only
make the installation more difficult.

Michal

[Patrick Vande Walle]

Post by Michal Ludvig

Post by Bob Apthorpe
I used Net::CIDR if it was there, otherwise I stuck with the
existing code

Aha. In that case the non-Net::CIDR implementation of IPv6 handling
should be fixed anyway, shouldn't it ;-)
And once everything works without Net::CIDR there's little point adding
a dependency on another nonstandard module. Unless it brings features
not available otherwise of course.
So -- what do we get from Net::CIDR that we can't have without? The
point is that sqlgrey shouldn't have unneeded dependencies that only
make the installation more difficult.

I can see several advantages in using Net::CIDR, beyond the cidrvalidate
functionality.

There is that general advantage of using proven, maintained code vs writing
an application-specific one. If the Perl modules gets a bug fix, so will
your application that depends on it.

Another advantage is regarding the clients_ip_whitelist file and table.
Right now, the read_an_ip_whitelist function only accepts IPv4 ranges that
are either /24 or /32 (or more precisely 3 or 4 octet addresses). This is
kind of broken by today's standards, where mail server farms can sometimes
be spread over /16s.

With the cidr_lookup function from Net::CIDR, SQLGrey would be able to
process not only to list IPv6 ranges, but also have more flexibility
regarding prefixes, both for IPv4 and IPv6. One could have specific
prefixes for each IP address range. This would require to re-write a
number of functions, though.

As a side note, I kind of solved the latter issue by storing everything in
a Postgresql table which uses the Postgresql cidr data type and adding a
function to SQLGrey to query that table. It is neither clean code nor is it
portable to MySQL or SQLite, because they do not have a similar data type.
Hence, I have not posted it here, but I can send it off-list to whoever is
interested.

Patrick Vande Walle

[Karl O. Pinc]

Post by Patrick Vande Walle

Post by Michal Ludvig
So -- what do we get from Net::CIDR that we can't have without? The
point is that sqlgrey shouldn't have unneeded dependencies that only
make the installation more difficult.

There is that general advantage of using proven, maintained code vs writing
an application-specific one. If the Perl modules gets a bug fix, so will
your application that depends on it.

This makes sense to me. Reinventing the wheel to keep down
dependencies seems counterproductive in today's world of modern
package management systems.


Karl <***@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein

[Lionel Bouton]

Post by Karl O. Pinc

Post by Patrick Vande Walle
There is that general advantage of using proven, maintained code vs writing
an application-specific one. If the Perl modules gets a bug fix, so will
your application that depends on it.

This makes sense to me. Reinventing the wheel to keep down
dependencies seems counterproductive in today's world of modern
package management systems.

I've seen many posts arguing for and against using Net::CIDR, but I'm
still wondering for which part of SQLgrey people want to use it. Anyone
can show code in the existing 1.7 branch that would benefit from
Net::CIDR and how?

Lionel