sqlgrey-users — Users of SQLgrey

[Sqlgrey-users] compute statistics

[Max D. <Max...@lr...>]

> Michael Storz wrote the following on 01.03.2005 21:43 :
> 
>> We are now in production for all our domains since a week. From our
>> statistics I see that about 6 % of all accepted emails are delayed.
>> 1/3 of these emails are DSNs. That gives us about 4 % "normal" emails.
>> What percentage do other sites see after running sqlgrey for a longer 
>> time
>> than we do?
>>  
>>
> 
> BTW one of my goal for the 1.5.x development series is providing a tool 
> to compute statistics like these. if you have something to start from, 
> I'd be happy to look at it.
> 
> Lionel.
> 

Hi All,

here are two perl scripts I used to aggregate some numbers from 
sqlgrey's logs. Then two shell scripts for visualizing the stats with 
rrdtool. May be this is interesting for someone.

Max
-- 
Max Diehn

-------------------------------------------------
Leibniz-Rechenzentrum   !   <mailto:di...@lr...>
Barer Str. 21           !
80333 Muenchen, Germany !   Tel: +49 89 289-27823

Re: [Sqlgrey-users] SQLgrey and IPv6

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

Klaus Alexander Seistrup wrote the following on 06.03.2005 13:12 :

>>- for 'smart' and 'classc', how do we compute the IPv6 network similar
>>to the IPv4 "x.x.x.0/24" network? For the common case, is removing the
>>last 32 bit hexadecimal component a good approach? Or are the IPv6
>>addresses addresses distributed to end-users in a way that makes it
>>possible to have wildly different systems in the same "/120" network?
>>    
>>
>
>I'm not sure.  Many tunnel brokers hand out /64 or /48 nets to end
>users.  E.g., I have [2001:1448:89::]/48 from ngdc.dk.  My impression
>is that IPv6/64 is somewhat similar to IPv4/32 (I'm not sure if
>IPv6/48 should be compared to IPv4/24, though). but that is highly
>subjective.
>  
>

I'm not sure IPv6/64 is the same as IPv4/32, I'll ask around as I know 
some ADSL users with IPv6 connectivity. My ideas on the subject should 
be clear before I step into IPv6 territory especially since I've no 
access to IPv6 for testing purposes myself.

One more thing: I need to know who will be able to test IPv6 support 
(I'm not able to). For testing, you'll need at least a Postfix 2.2 
pre-release (not a Postfix with an unofficial IPv6 patch...) or 2.2.x 
when it's out and some IPv6 SMTP trafic.

>  
>
>>- can we blindly remove the last :hexa component or are there
>>compression tricks in the representation that will prevent this? i.e.:
>> . common case "2001:4f8:3:ba:2e0:81ff:fe22:d1f1" ->
>>"2001:4f8:3:ba:2e0:81ff:fe22",
>> . imaginary problematic case: "2001:4f8:3:ba:2e0::" ->
>>"2001:4f8:3:ba:2e0:" (can it happen?).
>>    
>>
>
>As far as I know, compression always involves "::", so
>"2001:4f8:3:ba:2e0:" would never occur as shorthand for
>"2001:4f8:3:ba:2e0::".
>  
>

In the example "2001:4f8:3:ba:2e0:" wasn't meant to be an IPv6 address 
but the result of SQLgrey "client identifier" computation. For IPv4 
addresses it currently removes everything after the last ".", including 
the "." character itself.

What I wanted to say is that if it simply removes everything after the 
last ":" in the IPv6 case and "2001:4f8:3:ba:2e0::" is a valid IPv6 
address I'm expecting problems. On second thought the solution for this 
is obvious, just remove whatever comes after the ":" but don't remove 
the ":" character itself. I'm still wondering if there are some nasty 
things around I'm not expecting though.

Lionel.

Re: [Sqlgrey-users] SQLgrey and IPv6

[Klaus A. S. <kse...@gm...>]

Lionel Bouton wrote:

> Ooops, I forgot about IPv6. It seems as Postfix 2.2 is coming shortly
> with official IPv6 support we can now support it too.

:-)

> - what's the longest representation of an IPv6 address again?

1234:1234:1234:1234:1234:1234:1234:1234 =3D 39 characters

> - for 'smart' and 'classc', how do we compute the IPv6 network similar
> to the IPv4 "x.x.x.0/24" network? For the common case, is removing the
> last 32 bit hexadecimal component a good approach? Or are the IPv6
> addresses addresses distributed to end-users in a way that makes it
> possible to have wildly different systems in the same "/120" network?

I'm not sure.  Many tunnel brokers hand out /64 or /48 nets to end
users.  E.g., I have [2001:1448:89::]/48 from ngdc.dk.  My impression
is that IPv6/64 is somewhat similar to IPv4/32 (I'm not sure if
IPv6/48 should be compared to IPv4/24, though). but that is highly
subjective.

> - can we blindly remove the last :hexa component or are there
> compression tricks in the representation that will prevent this? i.e.:
>  . common case "2001:4f8:3:ba:2e0:81ff:fe22:d1f1" ->
> "2001:4f8:3:ba:2e0:81ff:fe22",
>  . imaginary problematic case: "2001:4f8:3:ba:2e0::" ->
> "2001:4f8:3:ba:2e0:" (can it happen?).

As far as I know, compression always involves "::", so
"2001:4f8:3:ba:2e0:" would never occur as shorthand for
"2001:4f8:3:ba:2e0::".
=20
>> Some time ago I switched from SQLite to PostgreSQL.  Any chance to
>> have SQLgrey use the INET storage type if database is PostgreSQL?
>=20
> In fact the original SQLgrey code used a PostgreSQL specific whitelist
> table using INET or CIDR. I removed this. I don't like database specific
> code. This make for more complex and less maintainable code.

Sure.
=20
> VARCHAR is probably less efficient than INET, but probably not enough to
> have PostgreSQL specific code.

I'm a lazy type of person, that's why I would like to use INET (or
CIDR) i SQLgrey.  The storage type handles IPv4 and IPv6 addresses
transparently, and it is very easy to test if a given IP address
belongs to a network ("SELECT foo FROM bar WHERE ip <<
'2001:1:2::/48'").

>> Would it be worth the trouble to put database specific rutines in
>> separate perl scripts, each having a similar API?  E.g. mysql-api.pm,
>> postgres-api.pm, sqlite-api.pm, ..., that each have a create_tables()
>> routine to create necessary tables.
>=20
> Probably not at this point. This could be used to avoid forking SQLgrey
> to support database specific code but you'll probably end with 90% of
> SQLgrey's code in the postgres-api.pm for example.

I see.

> IPv6 in TODO.

:-)

Cheers,

--=20
Klaus Alexander Seistrup
SubZeroNet =B7 Copenhagen =B7 Denmark

Re: [Sqlgrey-users] SQLgrey and IPv6

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

Klaus Alexander Seistrup wrote the following on 06.03.2005 11:22 :

>On Sun 19 Dec 2004, Lionel Bouton <lio...@bo...> wrote:
>
>  
>
>>What I can do is changing the table layouts in 1.5.x to handle the
>>maximum IPv6 address representation size (39 bytes).
>>    
>>
>
>Any news about the IPv6 issue?  I'm running SQLgrey v1.5.1, and the
>table layout still uses 15 charcters for storing IP addresses.
>
>  
>

Ooops, I forgot about IPv6. It seems as Postfix 2.2 is coming shortly 
with official IPv6 support we can now support it too.

It still will be tricky to handle. I need to learn a few things about 
IPv6 beforehand:

- what's the longest representation of an IPv6 address again?
- for 'smart' and 'classc', how do we compute the IPv6 network similar 
to the IPv4 "x.x.x.0/24" network? For the common case, is removing the 
last 32 bit hexadecimal component a good approach? Or are the IPv6 
addresses addresses distributed to end-users in a way that makes it 
possible to have wildly different systems in the same "/120" network?
- can we blindly remove the last :hexa component or are there 
compression tricks in the representation that will prevent this? i.e.:
 . common case "2001:4f8:3:ba:2e0:81ff:fe22:d1f1" -> 
"2001:4f8:3:ba:2e0:81ff:fe22",
 . imaginary problematic case: "2001:4f8:3:ba:2e0::" -> 
"2001:4f8:3:ba:2e0:" (can it happen?).

 From my reading of the Postfix documentation, we can at least rule out 
the programmer's nightmare of IPv4 in IPv6 addresses representations 
("::101.45.23.74" is a valid IPv6 address).

>Some time ago I switched from SQLite to PostgreSQL.  Any chance to
>have SQLgrey use the INET storage type if database is PostgreSQL?
>  
>

In fact the original SQLgrey code used a PostgreSQL specific whitelist 
table using INET or CIDR. I removed this. I don't like database specific 
code. This make for more complex and less maintainable code.

If INET proves to be useful it will probably be by allowing to handle 
some computations inside the database, it won't happen without a lot of 
code being reengineered for PostgreSQL. SQLgrey will probably have to 
fork into SQLgrey-generic and SQLgrey-PostgreSQL to make it easier to 
maintain.

VARCHAR is probably less efficient than INET, but probably not enough to 
have PostgreSQL specific code.
I'm not even sure that the performance difference will be measurable. 
INET is a complex storage type compared to VARCHAR, it must probably 
make provisions to store the type (IPv4/IPv6) and does store the network 
too -> it will use at least 17 bytes, probably more. On the other hand a 
VARCHAR IPv6 representation of an IPv4 address - the typical case - 
should be less than 20 bytes.

>Would it be worth the trouble to put database specific rutines in
>separate perl scripts, each having a similar API?  E.g. mysql-api.pm,
>postgres-api.pm, sqlite-api.pm, ..., that each have a create_tables()
>routine to create necessary tables.
>
>  
>

Probably not at this point. This could be used to avoid forking SQLgrey 
to support database specific code but you'll probably end with 90% of 
SQLgrey's code in the postgres-api.pm for example.

IPv6 in TODO.

Lionel.

Re: [Sqlgrey-users] SQLgrey and IPv6

[Klaus A. S. <kse...@gm...>]

On Sun 19 Dec 2004, Lionel Bouton <lio...@bo...> wrote:

> What I can do is changing the table layouts in 1.5.x to handle the
> maximum IPv6 address representation size (39 bytes).

Any news about the IPv6 issue?  I'm running SQLgrey v1.5.1, and the
table layout still uses 15 charcters for storing IP addresses.

Some time ago I switched from SQLite to PostgreSQL.  Any chance to
have SQLgrey use the INET storage type if database is PostgreSQL?

Would it be worth the trouble to put database specific rutines in
separate perl scripts, each having a similar API?  E.g. mysql-api.pm,
postgres-api.pm, sqlite-api.pm, ..., that each have a create_tables()
routine to create necessary tables.

Cheers,

--=20
Klaus Alexander Seistrup
SubZeroNet =B7 Copenhagen =B7 Denmark

Re: [Sqlgrey-users] RELEASE: 1.5.3 on SF

[Michel B. <mi...@bo...>]

Le Samedi 05 Mars 2005 10:19, Michel Bouissou a =E9crit :
>
> > As forking comes with some nasty gotchas, please send WORKSFORME repo=
rts
>
> At first sight, it seems to be WORKSFORME ;-)

Still WORKSFORME after 24h. I see cleanup children being forked, do their=
 job=20
then exit OK.

--=20
Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E

Re: [Sqlgrey-users] RELEASE: 1.5.3 on SF

[Michel B. <mi...@bo...>]

Le Samedi 05 Mars 2005 01:29, Lionel Bouton a =E9crit :
>
> 1.5.3 is out on sourceforge.
>
> The database cleanup is now done in a separate process forked each time
> sqlgrey thinks it should cleanup the database.

I could build a RPM straight from your tar.bz2 and install it OK.

Starting it logs:
Mar  5 10:15:25 totor sqlgrey: Process Backgrounded
Mar  5 10:15:25 totor sqlgrey: 2005/03/05-10:15:25 sqlgrey (type=20
Net::Server::Multiplex) starting! pid(730)
Mar  5 10:15:25 totor sqlgrey: Binding to TCP port 2501 on host localhost
Mar  5 10:15:25 totor sqlgrey: Setting gid to "1016 1016"
Mar  5 10:15:25 totor sqlgrey: Setting uid to "1016"
Mar  5 10:15:26 totor sqlgrey: Forked cleanup child (734)
Mar  5 10:15:26 totor sqlgrey: Spent 0s cleaning: from_awl (0) domain_awl=
 (0)=20
connect (0)
Mar  5 10:15:26 totor sqlgrey: Cleanup child exit (734)

> As forking comes with some nasty gotchas, please send WORKSFORME report=
s

At first sight, it seems to be WORKSFORME ;-)

--=20
Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E

[Sqlgrey-users] RELEASE: 1.5.3 on SF

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

Hi,

1.5.3 is out on sourceforge.

The database cleanup is now done in a separate process forked each time 
sqlgrey thinks it should cleanup the database.

If you have busy servers and the cleanup takes more time than you want 
Postfix to wait (see your logs unless you set 'quiet' in sqlgrey.conf), 
you may want to try this one.

Note to Gentoo users:
a new, much improved ebuild is available for 1.5.x releases, check the 
web page for a link and try it out (and look for the bug entry 
requesting its inclusion in Portage - enter ALL sqlgrey in the search 
box of bugs.gentoo.org - and add a comment :-)).

As forking comes with some nasty gotchas, please send WORKSFORME reports 
for this release. The forked process doesn't do much and the thing lives 
happily for more than 24hours on my MX but I had to take some 
precautions (look at the forked_cleanup function in the code) because 
SQLgrey now needs to create and destroy a second database connection, so 
you never know...

Lionel.

Re: [Sqlgrey-users] RELEASE: 1.5.2 on SF

[Michel B. <mi...@bo...>]

Le Jeudi 03 Mars 2005 15:59, Michel Bouissou a =E9crit :
>
> > The spec file is modified in order to be directly usable whatever the
> > distribution uses for man page compression (Michel, can you confirm i=
t
> > doesn't brake your RPMs?).
>
> The RPM builds here right from your archive without any change to the s=
pec
> file (or anything).
>
> Although I haven't installed it yet

As this message took about 24hrs to be distributed by the ML (waow...) I =
can=20
now say that I installed yesterday evening the sqlgrey-1.5.2-1.noarch.rpm=
=20
made straight out from your tar.gz, Lionel, and that it's been working fi=
ne=20
since.

No more specific patches this time :-)

--=20
Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E

Re: [Sqlgrey-users] RELEASE: 1.5.2 on SF

[Michel B. <mi...@bo...>]

Le Jeudi 03 Mars 2005 15:44, Lionel Bouton a =E9crit :
>
> The spec file is modified in order to be directly usable whatever the
> distribution uses for man page compression (Michel, can you confirm it
> doesn't brake your RPMs?).

The RPM builds here right from your archive without any change to the spe=
c=20
file (or anything).

Although I haven't installed it yet (taking a look at the changes, don't =
know=20
if I can test it today because I'm short in time...), I can see it does=20
include the bzip2 compressed manpage, so for me, it works:

[michel@totor SQLGrey]$ rpm -qlp sqlgrey-1.5.2-1.noarch.rpm
/etc/init.d/sqlgrey
/etc/sqlgrey/clients_fqdn_whitelist
/etc/sqlgrey/clients_ip_whitelist
/etc/sqlgrey/dyn_fqdn.regexp
/etc/sqlgrey/smtp_server.regexp
/etc/sqlgrey/sqlgrey.conf
/usr/sbin/sqlgrey
/usr/sbin/update_sqlgrey_config
/usr/share/doc/sqlgrey-1.5.2
/usr/share/doc/sqlgrey-1.5.2/Changelog
/usr/share/doc/sqlgrey-1.5.2/FAQ
/usr/share/doc/sqlgrey-1.5.2/HOWTO
/usr/share/doc/sqlgrey-1.5.2/README
/usr/share/doc/sqlgrey-1.5.2/TODO
/usr/share/man/man1/sqlgrey.1.bz2


--=20
Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E

[Sqlgrey-users] RELEASE: 1.5.2 on SF

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

Hi,

This one should bring better performance to PostgreSQL users by avoiding 
NOW() in WHERE statements.

The spec file is modified in order to be directly usable whatever the 
distribution uses for man page compression (Michel, can you confirm it 
doesn't brake your RPMs?).

Happy greylisting,

Lionel.

Re: [Sqlgrey-users] percentage of reconnect ok

[Michael S. <Mic...@lr...>]

On Thu, 3 Mar 2005, Lionel Bouton wrote:

> Michael Storz wrote the following on 01.03.2005 21:43 :
>
> >We are now in production for all our domains since a week. From our
> >statistics I see that about 6 % of all accepted emails are delayed.
> >1/3 of these emails are DSNs. That gives us about 4 % "normal" emails.
> >What percentage do other sites see after running sqlgrey for a longer time
> >than we do?
> >
> >
>
> Your milleage may vary :-)
>
> Not much stats here. I've had a report of 99% normal emails been
> whitelisted but for a MXs handling only 3 domains and less than a
> thousand mailboxes with very predictible email usage patterns (these are
> not personal mailboxes but business ones).
>
> Last time I looked, for my own MX with only my mailboxes, I was more in
> the 99,5 ballpark :-)

Thanks for the answer, my hope is to get in the same range. At least the
numbers are dropping, unfortunately very slowly.

>
> How much mailboxes do you handle and which type of customers are there
> behind?

Difficult to say. I have about 70.000 mailboxes with 180 different
domains. But we also relay traffic for a lot of small local mailservers
behind us, playing the email firewall system for them. All out users are
in scientific area, several universities etc.

Regards,
Michael Storz
-------------------------------------------------
Leibniz-Rechenzentrum   !   <mailto:St...@lr...>
Barer Str. 21           !   Fax: +49 89 2809460
80333 Muenchen, Germany !   Tel: +49 89 289-28840

Re: [Sqlgrey-users] percentage of reconnect ok

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

Michael Storz wrote the following on 01.03.2005 21:43 :

>We are now in production for all our domains since a week. From our
>statistics I see that about 6 % of all accepted emails are delayed.
>1/3 of these emails are DSNs. That gives us about 4 % "normal" emails.
>What percentage do other sites see after running sqlgrey for a longer time
>than we do?
>  
>

BTW one of my goal for the 1.5.x development series is providing a tool 
to compute statistics like these. if you have something to start from, 
I'd be happy to look at it.

Lionel.

Re: [Sqlgrey-users] percentage of reconnect ok

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

Michael Storz wrote the following on 01.03.2005 21:43 :

>We are now in production for all our domains since a week. From our
>statistics I see that about 6 % of all accepted emails are delayed.
>1/3 of these emails are DSNs. That gives us about 4 % "normal" emails.
>What percentage do other sites see after running sqlgrey for a longer time
>than we do?
>  
>

Your milleage may vary :-)

Not much stats here. I've had a report of 99% normal emails been 
whitelisted but for a MXs handling only 3 domains and less than a 
thousand mailboxes with very predictible email usage patterns (these are 
not personal mailboxes but business ones).

Last time I looked, for my own MX with only my mailboxes, I was more in 
the 99,5 ballpark :-)

How much mailboxes do you handle and which type of customers are there 
behind?

Cheers,

Lionel

Re: [Sqlgrey-users] RELEASE: 1.5.1 on sourceforge

[Michel B. <mi...@bo...>]

Le Mercredi 02 Mars 2005 18:19, Lionel Bouton a =E9crit :
>
> Michel, is there a way to make various rpm versions happy with a same
> spec file on this?

/usr/share/man/man1/sqlgrey.1*
would most probably do the trick ;-)

--=20
Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E

Re: [Sqlgrey-users] RELEASE: 1.5.1 on sourceforge

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

Michel Bouissou wrote the following on 02.03.2005 17:25 :

>Le Mercredi 02 Mars 2005 13:59, Lionel Bouton a =E9crit :
> =20
>
>>1.5.1 is out. It uses Michel's algorithm to guess if the IP is more
>>likely to be an SMTP server or a personnal connexion.
>>   =20
>>
>
>Great. I've seen you couldn't resist to the pleasure of putting the actu=
al=20
>regexps in separate config files ;-)
>
>...hope users won't mess with them too much.
>

Yes, there's a warning in the README installed by the update script for=20
this very reason.

> IMHO, these files would have been=20
>better somewhere in /usr/lib rather than /etc.
>
> =20
>

Hum, it really depends on how you see these files. From SQLgrey's point=20
of view these are configuration files. Now if you use the update script=20
(which is recommended) they look more like resource files as they aren't=20
meant to be modified by the admin anymore. In this case I think a more=20
suitable place would be /usr/share/sqlgrey.
But I want to remain flexible on the way these files are handled. The=20
admin should be able to set up its own repository if mine doesn't suit=20
him/her, or even scrap the update script and use whatever suits his/her=20
needs.

What is obviously lacking is a more detailed description of these files=20
so as to allow people interested in tweaking them to understand how to=20
do it.


>An RPM package for 1.5.1 is on http://www.bouissou.net/sqlgrey/
>
>It incorporates my "unofficial" date interval calculation patch as attac=
hed.
>
> =20
>

I must code the replacement for all now() usages. If all goes as well as=20
my initial tests did show, you won't have to maintain this part of your=20
patch after that. Look forward for 1.5.2.

>@@ -38,7 +45,7 @@
> /etc/init.d/sqlgrey
> /usr/sbin/sqlgrey
> /usr/sbin/update_sqlgrey_config
>-/usr/share/man/man1/sqlgrey.1.gz
>+/usr/share/man/man1/sqlgrey.1.bz2
> =20
>

Michel, is there a way to make various rpm versions happy with a same=20
spec file on this? For example on Gentoo the man page isn't compressed=20
by the ebuild, the package manager automagically compress any man pages.=20
Is there something along these lines that could be used in a portable=20
way with RPM?

If not, I'll have to include a make mandrakerpm using a separate spec=20
file :-/

Lionel.

Re: [Sqlgrey-users] RELEASE: 1.5.1 on sourceforge

[Michel B. <mi...@bo...>]

Le Mercredi 02 Mars 2005 13:59, Lionel Bouton a =E9crit :
>
> 1.5.1 is out. It uses Michel's algorithm to guess if the IP is more
> likely to be an SMTP server or a personnal connexion.

Great. I've seen you couldn't resist to the pleasure of putting the actua=
l=20
regexps in separate config files ;-)

...hope users won't mess with them too much. IMHO, these files would have=
 been=20
better somewhere in /usr/lib rather than /etc.

An RPM package for 1.5.1 is on http://www.bouissou.net/sqlgrey/

It incorporates my "unofficial" date interval calculation patch as attach=
ed.

Cheers.

--=20
Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E

[Sqlgrey-users] RELEASE: 1.5.1 on sourceforge

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

Hi,

1.5.1 is out. It uses Michel's algorithm to guess if the IP is more 
likely to be an SMTP server or a personnal connexion.

update_sqlgrey_whitelists is replaced by update_sqlgrey_config as it now 
fetches other config files (namely 2 regexps used by Michel's algorithm 
and a README file).

Best regards,

Lionel.

Re: [Sqlgrey-users] Weird update_sqlgrey_whitelists messages

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

Michel Bouissou wrote the following on 02.03.2005 09:00 :

>This ? From my last nitgh's cron jobs report:
><<<<<
>updating /etc/sqlgrey/README:
>rm: cannot remove `README': No such file or directory
>/usr/bin/diff: /etc/sqlgrey/README: No such file or directory
>updating /etc/sqlgrey/dyn_fqdn.regexp:
>rm: cannot remove `dyn_fqdn.regexp': No such file or directory
>/usr/bin/diff: /etc/sqlgrey/dyn_fqdn.regexp: No such file or directory
>updating /etc/sqlgrey/smtp_server.regexp:
>rm: cannot remove `smtp_server.regexp': No such file or directory
>/usr/bin/diff: /etc/sqlgrey/smtp_server.regexp: No such file or directory
>  
>
>
>  
>
That's it :-)

Re: [Sqlgrey-users] Weird update_sqlgrey_whitelists messages

[Michel B. <mi...@bo...>]

Le Mercredi 02 Mars 2005 02:06, Lionel Bouton a =E9crit :
>
> I'm currently testing the 1.5.1 release and new files will be
> distributed by the central repository to people using
> update_sqlgrey_whitelists (updateable regexps for the new smart
> algorithm and a README).
>
> As I didn't check for the case where new files are introduced, there
> will be some harmless error messages reported

This ? From my last nitgh's cron jobs report:
<<<<<
updating /etc/sqlgrey/README:
rm: cannot remove `README': No such file or directory
/usr/bin/diff: /etc/sqlgrey/README: No such file or directory
updating /etc/sqlgrey/dyn_fqdn.regexp:
rm: cannot remove `dyn_fqdn.regexp': No such file or directory
/usr/bin/diff: /etc/sqlgrey/dyn_fqdn.regexp: No such file or directory
updating /etc/sqlgrey/smtp_server.regexp:
rm: cannot remove `smtp_server.regexp': No such file or directory
/usr/bin/diff: /etc/sqlgrey/smtp_server.regexp: No such file or directory
>>>>>

--=20
Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E

[Sqlgrey-users] Weird update_sqlgrey_whitelists messages

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

I'm currently testing the 1.5.1 release and new files will be 
distributed by the central repository to people using 
update_sqlgrey_whitelists (updateable regexps for the new smart 
algorithm and a README).

As I didn't check for the case where new files are introduced, there 
will be some harmless error messages reported, but the files will be 
downloaded and on subsequent runs the update script won't complain.

update_sqlgrey_whitelists will be replaced by a patched and better-named 
update_sqlgrey_config starting with 1.5.1...

Lionel.

[Sqlgrey-users] percentage of reconnect ok

[Michael S. <Mic...@lr...>]

We are now in production for all our domains since a week. From our
statistics I see that about 6 % of all accepted emails are delayed.
1/3 of these emails are DSNs. That gives us about 4 % "normal" emails.
What percentage do other sites see after running sqlgrey for a longer time
than we do?

Michael Storz
-------------------------------------------------
Leibniz-Rechenzentrum   !   <mailto:St...@lr...>
Barer Str. 21           !   Fax: +49 89 2809460
80333 Muenchen, Germany !   Tel: +49 89 289-28840

Re: [Sqlgrey-users] DEV RELEASE 1.5.0

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

Michel Bouissou wrote the following on 26.02.2005 11:11 :

>Le Mercredi 23 F=E9vrier 2005 01:50, Lionel Bouton a =E9crit :
> =20
>
>>1.5.0 is out on sourceforge.
>>   =20
>>
>[...]
> =20
>
>>This is the SQLgrey's version I'm currently using on my MX...
>>So it's "worksforme" material.
>>   =20
>>
>
>I've installed it here, patched with the attached patch that reintroduce=
s the=20
>Big Ugly Regexp (which I love;-)
>

I just made a little bench of the new Big Ugly Regexp smart algorithm=20
and the old simpler one.
On my workstation (AthlonXP 2400+) , the old managed to take decisions=20
on one million IP/FQDN couples in 10s, the new one in 23s.

I don't think that even hotmail.com would see a significant CPU usage=20
change by switching from the old algorithm to the new one :-)

The regexp based algorithm will replace the old 'smart' in 1.5.1.

Lionel.

Re: [Sqlgrey-users] DEV RELEASE 1.5.0

[Michel B. <mi...@bo...>]

Le Mercredi 23 F=E9vrier 2005 01:50, Lionel Bouton a =E9crit :
>
> 1.5.0 is out on sourceforge.
[...]
> This is the SQLgrey's version I'm currently using on my MX...
> So it's "worksforme" material.

I've installed it here, patched with the attached patch that reintroduces=
 the=20
Big Ugly Regexp (which I love;-) an date calculations in Perl (which are =
my=20
own experimentations ;-)

So far so good, it seems to work and converted my V.1 PostgreSQL DB OK.

A Mandrake RPM including my patch is available at=20
http://www.bouissou.net/sqlgrey/

Cheers.

--=20
Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E

[Sqlgrey-users] Re: Sqlgrey-users digest, Vol 1 #69 - 3 msgs

[Chris H. <ch...@me...>]

> If I understand correctly, MXLogic acts like a proxy and not as a real
> MTA (ie : it doesn't store the messages, only filters on the fly and
> accepts a message only if your servers accept it too which make
> greylisting useful even behind them). Seems like a good service.

Exactly.  And the price is right - costs me about 55 cents a subscriber, for 
spam and virus filtering.
Of course...sqlgrey is a better deal....