sqlgrey-users — Users of SQLgrey

Re: [Sqlgrey-users] Improved dynamic/one-shot email address regex

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

Jeff Rice wrote the following on 21.09.2005 18:58 :

>Lionel Bouton wrote:
> > Good, I believe this is useful. Note: the case insensitive match isn't
>  
>
>>needed. All addresses are lowercased before being processed. I removed
>>it from all your substitution.
>>    
>>
>
>Good to know.  The other VERP I am experimenting with deals with a
>number of emails I get that don't contain tell-tale signs (like -,_, or
>.) but are otherwise one-shot emails.  At the moment, I am assuming that
>if an email name contains more than 7 consecutive digits, the whole name
>should be masked.  I have never seen a normal email account with that
>many digits in a row.
>
># mask long numeric sequences
>$user =~ s/.*[0-9]{7,}.*/#/g;
>  
>

Doesn't that simply replace any string with at least seven successive  
numerical characters by a sharp?

I would have used:

$user =~ s/[0-9]{7,}/#/g;


Lionel.

Re: [Sqlgrey-users] Improved dynamic/one-shot email address regex

[Jeff R. <py...@fi...>]

Lionel Bouton wrote:
 > Good, I believe this is useful. Note: the case insensitive match isn't
> needed. All addresses are lowercased before being processed. I removed
> it from all your substitution.

Good to know.  The other VERP I am experimenting with deals with a
number of emails I get that don't contain tell-tale signs (like -,_, or
.) but are otherwise one-shot emails.  At the moment, I am assuming that
if an email name contains more than 7 consecutive digits, the whole name
should be masked.  I have never seen a normal email account with that
many digits in a row.

# mask long numeric sequences
$user =~ s/.*[0-9]{7,}.*/#/g;

This may be less-useful in the wild, but seems to function well enough
for me.  The only drawback I can foresee is that this will probably mask
emails that are sent by cellphones/pagers etc. since those are often use
the phone number as the user name.

This and the other patch may very well need tweaking, so it would be
useful if people could look at their from_awl tables and see how things
are looking.

Jeff

[Sqlgrey-users] Contributions

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

There is a significant amount of work in SQLgrey not from me. I've=20
always feeled like it was not fair neither polite that this work wasn't=20
properly acknowledged in SQLgrey.

Here is a CONTRIB file I'd add to SQLgrey. If you feel that your=20
contribution was missed, please remind me of it (I went through the=20
Changelog to build this file so I probably missed something).

## CONTRIB BEGIN ##
Several people helped during SQLgrey development:

Jeff Rice:
- VERP tuning (especially for bounce/notify messages) (1.7.2),

Michel Bouissou:
- source IP throttling (tarpitting) (1.7.0),
- better connect cleanup when moving entries in AWL (1.7.0),
- new 'smart' greylisting algorithm, replacing previous one (1.5.1),
- portability fixes in update_sqlgrey_config (1.4.5)
- configurable return code (1.4.5)
- VERP and SRS tuning (1.4.5)

Rene Joergensen:
- better cleanup logging (1.4.2)

=D8ystein Viggen:
- fix for startup warning messages (1.4.1)
- found an SQL injection vulnerability (fixed in 1.4.0)

Derek Battams:
- ideas for different greylisting algorithms (implemented in 1.3.6)

Klaus Alexander Seistrup:
- idea for SQLite support (implemented in 1.1.0)

Numerous others helped with great ideas or bug reports.
## CONTRIB END ##

Re: [Sqlgrey-users] Re: create_connect_table at /usr/sbin/sqlgrey line 176.

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

Evert Meulie wrote the following on 21.09.2005 15:17 :

> Dropping all the existing tables in my sqlgrey database solved the 
> problem...   8-)


Ouch ! Can you at least tell us which database you used so that I can 
try to trigger the problem?

Re: [Sqlgrey-users] create_connect_table at /usr/sbin/sqlgrey line 176.

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

Evert Meulie wrote the following on 21.09.2005 14:41 :

> Hi all!
>
> When I start version 1.6.6 of sqlgrey, I get the following error message:
>
>     create_connect_table at /usr/sbin/sqlgrey line 176.
>
> This is after an upgrade from version 1.4.8


Is this the only thing you get in the logs?

Does sqlgrey crash then or continue?

If it crashes:
- what are the table definitions (for tables connect, from_awl and 
domain_awl)? (you can use DESC tablename in MySQL or \d tablename for 
PostgreSQL).
- what is the result of : "SELECT * from config ;"

Lionel.

[Sqlgrey-users] Re: create_connect_table at /usr/sbin/sqlgrey line 176.

[Evert M. <ev...@wi...>]

Dropping all the existing tables in my sqlgrey database solved the problem...   8-)

    Evert


Evert Meulie wrote:
> Hi all!
> 
> When I start version 1.6.6 of sqlgrey, I get the following error message:
> 
>     create_connect_table at /usr/sbin/sqlgrey line 176.
> 
> This is after an upgrade from version 1.4.8
> 
> 
> Regards,
>     Evert
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. 
> Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: [Sqlgrey-users] Improved dynamic/one-shot email address regex

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

Jeff Rice wrote the following on 21.09.2005 00:14 :

>Hi,
>Just thought I would share a small patch that deals with a number of
>single-use email addresses that weren't being recognized by the existing
>regex in sqlgrey.  These are the sort of bounce-return-12310123981, etc.
> This patch just tries to mask the parts that appear to be unique, so
>the database doesn't get filled with addresses that won't be used again.
>
>I somewhat arbitrarily decided that if an email name contained a
>delimiter such as "-","_", or "." along with a string of 12 or more
>alphanumeric characters, then those characters should be masked.  That
>may or may not result in some emails being masked when they should not,
>or some not being masked when they should.  I don't believe the result
>will be tragic in either case, and this can be adjusted to your liking.
>
>It might not work as well for other folks, but it seems to catch the
>major ones I see.  I am sure there are other patterns that I didn't
>catch simply because they don't come up frequently in my email mix.
>
>Jeff
>  
>

Thanks, added in the 1.7.x branch, will be in 1.7.2. Comments below in 
the patch.

>--- sqlgrey 2005-09-03 01:09:21.000296554 +0000
>+++ /usr/sbin/sqlgrey   2005-09-03 01:09:02.000989883 +0000
>@@ -986,14 +986,21 @@
>     $user =~ s/^srs1=[^=]+=([^=]+)(=+)[^=]+=[^=]+=([^=]+)=([^=]+)$/srs1=#=$1$2#=#=$3=$4/;
>     # strip extension, used sometimes for mailing-list VERP
>     $user =~ s/\+.*//;
>+
>+    # strip frequently used bounce/return masks
>+    $user =~ s/((bo|bounce|notice-return|notice-reply)[._-])[0-9a-z-_.]+$/$1#/gi;   # Added by JR
>+
>  
>

Good, I believe this is useful. Note: the case insensitive match isn't 
needed. All addresses are lowercased before being processed. I removed 
it from all your substitution.

>     # strip hexadecimal sequences (doable in one regexp ?)
>     # don't strip a leading hex sequence though
>     my $tmp = '';
>     while ($tmp ne $user) {
>    $tmp = $user;
>    $user =~ s/([._-])[0-9a-f]+([._-])/$1#$2/g;
>-    }
>+   $user =~ s/([._-])[0-9a-z]{12,}([._-])/$1#$2/gi;                                # Added by JR
>  
>

12 is arbitrary but seems good to me. I'm not sure how this one will 
play out in the wild (this is why I prefer to put this code in the 1.7.x 
branch).

>+
>+   }
>     $user =~ s/([._-])[0-9a-f]+$/$1#/g;
>+    $user =~ s/([._-])[0-9a-z]{12,}$/$1#/gi;                                       # Added by JR
>  
>

OK

Lionel.

[Sqlgrey-users] create_connect_table at /usr/sbin/sqlgrey line 176.

[Evert M. <ev...@wi...>]

Hi all!

When I start version 1.6.6 of sqlgrey, I get the following error message:

	create_connect_table at /usr/sbin/sqlgrey line 176.

This is after an upgrade from version 1.4.8


Regards,
	Evert

[Sqlgrey-users] Improved dynamic/one-shot email address regex

[Jeff R. <py...@fi...>]

Hi,
Just thought I would share a small patch that deals with a number of
single-use email addresses that weren't being recognized by the existing
regex in sqlgrey.  These are the sort of bounce-return-12310123981, etc.
 This patch just tries to mask the parts that appear to be unique, so
the database doesn't get filled with addresses that won't be used again.

I somewhat arbitrarily decided that if an email name contained a
delimiter such as "-","_", or "." along with a string of 12 or more
alphanumeric characters, then those characters should be masked.  That
may or may not result in some emails being masked when they should not,
or some not being masked when they should.  I don't believe the result
will be tragic in either case, and this can be adjusted to your liking.

It might not work as well for other folks, but it seems to catch the
major ones I see.  I am sure there are other patterns that I didn't
catch simply because they don't come up frequently in my email mix.

Jeff

Re: [Sqlgrey-users] A new client_ip_whitelist entry...

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

Steffen Plotner wrote the following on 15.09.2005 19:05 :

>Hello Lionel,
>
>192.204.19.13   # discovery.acnatsci.org (they have groupwise 5.5)
>
>The entry above uses groupwise 5.5 (from 1996) that does not understand
>the transient 450 error code, it translates that into 554 error (no
>valid recipients). I contacted the organization, they know about it and
>informed me that they are upgrading to a current version of groupwise in
>the next few months.
>
>  
>

Added to the repository with a reminder to check them in 2006.
Too bad they don't have reverse DNS entries too, if they move the 
server, the whitelist entry is lost for them...

[Sqlgrey-users] A new client_ip_whitelist entry...

[Steffen P. <swp...@am...>]

Hello Lionel,

192.204.19.13   # discovery.acnatsci.org (they have groupwise 5.5)

The entry above uses groupwise 5.5 (from 1996) that does not understand
the transient 450 error code, it translates that into 554 error (no
valid recipients). I contacted the organization, they know about it and
informed me that they are upgrading to a current version of groupwise in
the next few months.

Steffen

[Sqlgrey-users] [BUGFIX RELEASE] 1.7.1

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

1.7.1 is on sourceforge with forward-ported patches from 1.6.6:

http://sourceforge.net/project/showfiles.php?group_id=113566&package_id=135376&release_id=356704

1.6.6 RPMs are now uploaded too:

http://sourceforge.net/project/showfiles.php?group_id=113566&package_id=155492&release_id=356574

Lionel.

Re: [Sqlgrey-users] SQLGrey in Portage

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

Ray Booysen wrote the following on 15.09.2005 10:06 :

> Hi Lionel
>
> Any update from Gentoo when SQLGrey might hit portage?  Looking at the 
> bug at bugs.gentoo.org someone said he would be taking it on.  Nothing 
> yet?


AFAIKT nothing (bugs.gentoo.org is the reference anyway, if an "ebuild 
bug" is still in there without a message saying the package has been 
commited to the tree, it is most likely still out of Portage).
But putting new ebuilds in the bug entry shows that the package is 
maintained, it will help get a developer's attention eventually. The 
developers are more or less buried alive under requests to put new 
packages in Portage anyway, these things take a lot of time (because of 
QA without which Gentoo would be a large piece of crap full of software 
instead of a polished distribution), especially for projects with a 
comparatively small userbase like SQLgrey.

Lionel.

Re: [Sqlgrey-users] [BUGFIX RELEASE] 1.6.6

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

Michel Bouissou wrote the following on 15.09.2005 10:13 :

>Le Mercredi 14 Septembre 2005 22:26, Lionel Bouton a =E9crit :
> =20
>
>>1.6.6 is on sourceforge
>>   =20
>>
>
>Hi Lionel,
>
>And what about the 1.7.x development series with the nice throttling fea=
ture ?
>
>Do you plan to integrate the latest 1.6 series fixes to 1.7 anytime soon=
 ?
>
> =20
>

Yes, today.

>Do you have a schedule for future 1.7.x developments ?
> =20
>

The 1.7.0 TODO is more or less the order in which I intend to implement=20
things.

Lionel.

Re: [Sqlgrey-users] [BUGFIX RELEASE] 1.6.6

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

Le Mercredi 14 Septembre 2005 22:26, Lionel Bouton a =E9crit :
> 1.6.6 is on sourceforge

Hi Lionel,

And what about the 1.7.x development series with the nice throttling feat=
ure ?

Do you plan to integrate the latest 1.6 series fixes to 1.7 anytime soon =
?

Do you have a schedule for future 1.7.x developments ?

I use 1.7.0 since its release and feel perfectly happy with it, but I'd l=
ike=20
to see develoment continue and bugfixes to 1.6.x being committed to 1.7.x=
 as=20
well...

Cheers.

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

[Sqlgrey-users] SQLGrey in Portage

[Ray B. <rj_...@rj...>]

Hi Lionel

Any update from Gentoo when SQLGrey might hit portage?  Looking at the 
bug at bugs.gentoo.org someone said he would be taking it on.  Nothing yet?

Regards
Raye

Re: [Sqlgrey-users] [BUGFIX RELEASE] 1.6.6

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

Ray Booysen wrote the following on 15.09.2005 09:43 :

> Hi Lionel
>
> Can I use the 1.6.5 ebuild and just rename it?


Yes. You can download the 1.6.6 from the sourceforge page too, but it's 
really the same file :-)

Lionel.

Re: [Sqlgrey-users] [BUGFIX RELEASE] 1.6.6

[Ray B. <rj_...@rj...>]

Lionel Bouton wrote:
> Hi,
> 
> 1.6.6 is on sourceforge, currently only the tar.bz2 is available. I'll 
> generate RPMS tomorrow.
> 
> http://sourceforge.net/project/showfiles.php?group_id=113566&package_id=155492&release_id=356574 
> 
> 
> This should fix the bug found by Steffen (race condition in multiple 
> instances configs which leads to mail being delayed indefinitely).
> There's a bugfix for the weekly stats that was waiting in the pipe too.
> 
> Lionl.
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. 
> Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Sqlgrey-users mailing list
> Sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlgrey-users
Hi Lionel

Can I use the 1.6.5 ebuild and just rename it?

Regards
Ray

RE: [Sqlgrey-users] [BUGFIX RELEASE] 1.6.6

[Steffen P. <swp...@am...>]

(The previous reply/posting was incomplete - sorry)

Hi Lionel,

I would like to thank you for the quick turn around fixing this issue. I
studied the changes, and the logic is now clear to me what happened (a
raise condition between the 2 grey listing servers, and a comparison of
the number of rows in the connect table for a given set that IF there
was more than 1 it would not return 'at least one entry' - it now does).
Thank you. =20

The user community of Amherst College has stated at several occassions
their appreciation of the reduction of incoming spam.

Our setup used to be 2 MailScanner servers -> Exchange. We then
purchased the Barracuda spam firewall and found that its spam flagging
capabilities are outstanding (with only one problem - still way too much
spam).

We then implemented postfix+rbl+sqlgrey -> barracuda -> exchange. Now
things look really good.=20

The postfix server processes 30-50 incoming messages/minute/server
continously. Using the averages we have the following breakdown:=20

22.85%	passed to barracuda for further processing

28.57% greylisted (we have close to 100k rows and growing in the
awl_from table and 1700 in domain_awl, we average about 20k rows in the
connect table, steady)

42.85% rejected due to RBLs

5.71% reject due to malformed sender domains and so on.

So, we have 77% of incoming stuff is spam of some kind. 23% is for real.
The barracudas used to flag the 77% of mail as spam since we had no RBL
filters, greylisting in place. Now the barracudas barely flag anything
spam.

In conclusion, I have to say this is a effective method against the
current state of the spam warfare.

Great job, Lionel.

Steffen


-----Original Message-----
From: sql...@li...
[mailto:sql...@li...] On Behalf Of Lionel
Bouton
Sent: Wednesday, September 14, 2005 4:26 PM
To: sql...@li...
Subject: [Sqlgrey-users] [BUGFIX RELEASE] 1.6.6

Hi,

1.6.6 is on sourceforge, currently only the tar.bz2 is available. I'll
generate RPMS tomorrow.

http://sourceforge.net/project/showfiles.php?group_id=3D113566&package_id=
=3D
155492&release_id=3D356574

This should fix the bug found by Steffen (race condition in multiple
instances configs which leads to mail being delayed indefinitely).
There's a bugfix for the weekly stats that was waiting in the pipe too.

Lionl.


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your
very own Sony(tm)PSP.  Click here to play:
http://sourceforge.net/geronimo.php
_______________________________________________
Sqlgrey-users mailing list
Sql...@li...
https://lists.sourceforge.net/lists/listinfo/sqlgrey-users

RE: [Sqlgrey-users] [BUGFIX RELEASE] 1.6.6

[Steffen P. <swp...@am...>]

Hi Lionel,

I would like to thank you for the quick turn around fixing this issue. I
studied the changes, and the logic is now clear to me what happened (a
raise condition between the 2 grey listing servers, and a comparison of
the number of rows in the connect table for a given  that IF there was
more than 1 it would not return 'at least one entry' - it now does).
Thank you. =20

The user community of Amherst College has stated at several occassions
their appreciation of the reduction of incoming spam.
=20

-----Original Message-----
From: sql...@li...
[mailto:sql...@li...] On Behalf Of Lionel
Bouton
Sent: Wednesday, September 14, 2005 4:26 PM
To: sql...@li...
Subject: [Sqlgrey-users] [BUGFIX RELEASE] 1.6.6

Hi,

1.6.6 is on sourceforge, currently only the tar.bz2 is available. I'll
generate RPMS tomorrow.

http://sourceforge.net/project/showfiles.php?group_id=3D113566&package_id=
=3D
155492&release_id=3D356574

This should fix the bug found by Steffen (race condition in multiple
instances configs which leads to mail being delayed indefinitely).
There's a bugfix for the weekly stats that was waiting in the pipe too.

Lionl.


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your
very own Sony(tm)PSP.  Click here to play:
http://sourceforge.net/geronimo.php
_______________________________________________
Sqlgrey-users mailing list
Sql...@li...
https://lists.sourceforge.net/lists/listinfo/sqlgrey-users

[Sqlgrey-users] [BUGFIX RELEASE] 1.6.6

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

Hi,

1.6.6 is on sourceforge, currently only the tar.bz2 is available. I'll 
generate RPMS tomorrow.

http://sourceforge.net/project/showfiles.php?group_id=113566&package_id=155492&release_id=356574

This should fix the bug found by Steffen (race condition in multiple 
instances configs which leads to mail being delayed indefinitely).
There's a bugfix for the weekly stats that was waiting in the pipe too.

Lionl.

Re: [Sqlgrey-users] Duplicate connect records

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

Steffen Plotner wrote the following on 14.09.2005 20:51 :

>Hello Lionel,
>
>Yesterday, I really did have duplications for whatever reason I have not
>determined yet. The duplications I thought I had today were incorrectly
>queried for. The query should have been:
>
>select sender_name, sender_domain, src,
>count(sender_name+sender_domain+src+rcpt) as count 
>from connect 
>group by sender_name, sender_domain, src, rcpt 
>having count(sender_name+sender_domain+src+rcpt) > 1;
>
>Which includes the rcpt field in the group and I have NO duplications.
>
>So, that leaves us with why did I have duplications.
>
>Would you mind explaining the syntax you use in your perl code (I use
>perl a bit, however I admit that I am not totally clear about the syntax
>below:), in particularly the $#$ part, I understand that the $result is
>contains a reference:
>
>    if ($#$result != 0) {
>        return 0; # not a single entry
>    } else {
>        return 1; # at least one entry
>    }
>
>Thinking that it might mean the number of records (?) I wrote a little
>script to check this:
>
>' the query SHOULD return ONE record (at least in my connect table, just
>substitute the value below...
>
>my $sth = $dbconn->prepare("SELECT * FROM connect WHERE sender_name =
>'zwsfkz'");
>
>my $result = $sth->fetchall_arrayref();
>print "$#$result \n";
>
>$sth->execute();
>my $count=0;
>while ( my $row = $sth->fetchrow_hashref() )
>{
>	$count++;
>}
>print "$count\n";
>
>And I find that the first value is always one less than the actual
>count. Hmmm. 
>
>  
>

I just realized that I introduced a bug not so long ago. It seems you 
are the first to be hit and you were on the right track above (the logic 
is now flawed when deciding if an entry in connect must be created).
SQLgrey serializing each message processing the bug can only hit 
installs with multiple greylisting servers: the symptom is mail being 
delayed indefinitely (ouch!). It's a race condition that can be hard to 
hit : there are 2 cases I can think of :
- the other server must try at least two MXs at the same time without 
waiting for the first answer (can't imagine why one normal SMTP server 
would try the same delivery on every MX, only SPAM sources might try that).
- one server (or several in the same class-C) delivers several messages 
from the same source to the same destination at the exact same time 
(given the observed timings, far less than a second apart) and uses 
different MX for that.

Until recently, the put_in_connect function added as a precaution a 
"DELETE FROM connect ..." cleaning entries that might conflict with the 
one being inserted. In order to save a SQL query and speed SQLgrey a 
little bit, I removed some dependencies in the code to the fact that no 
identical entries (save from the timestamp) must be in connect at the 
same time but it seems I forgot to adapt the logic in some places.

Expect a 1.6.6 release with the bugfix shortly tonight.

Lionel.

RE: [Sqlgrey-users] Duplicate connect records

[Steffen P. <swp...@am...>]

Hello Lionel,

Yesterday, I really did have duplications for whatever reason I have not
determined yet. The duplications I thought I had today were incorrectly
queried for. The query should have been:

select sender_name, sender_domain, src,
count(sender_name+sender_domain+src+rcpt) as count=20
from connect=20
group by sender_name, sender_domain, src, rcpt=20
having count(sender_name+sender_domain+src+rcpt) > 1;

Which includes the rcpt field in the group and I have NO duplications.

So, that leaves us with why did I have duplications.

Would you mind explaining the syntax you use in your perl code (I use
perl a bit, however I admit that I am not totally clear about the syntax
below:), in particularly the $#$ part, I understand that the $result is
contains a reference:

    if ($#$result !=3D 0) {
        return 0; # not a single entry
    } else {
        return 1; # at least one entry
    }

Thinking that it might mean the number of records (?) I wrote a little
script to check this:

' the query SHOULD return ONE record (at least in my connect table, just
substitute the value below...

my $sth =3D $dbconn->prepare("SELECT * FROM connect WHERE sender_name =
=3D
'zwsfkz'");

my $result =3D $sth->fetchall_arrayref();
print "$#$result \n";

$sth->execute();
my $count=3D0;
while ( my $row =3D $sth->fetchrow_hashref() )
{
	$count++;
}
print "$count\n";

And I find that the first value is always one less than the actual
count. Hmmm.=20


-----Original Message-----
From: sql...@li...
[mailto:sql...@li...] On Behalf Of Steffen
Plotner
Sent: Wednesday, September 14, 2005 11:24 AM
To: sql...@li...
Subject: RE: [Sqlgrey-users] Duplicate connect records

Hi Lionel,

I use a shell script using scp to sync the sqlgrey.conf files on both
servers. I just checked them and they match.=20

Steffen=20

-----Original Message-----
From: sql...@li...
[mailto:sql...@li...] On Behalf Of Lionel
Bouton
Sent: Wednesday, September 14, 2005 11:16 AM
To: sql...@li...
Subject: Re: [Sqlgrey-users] Duplicate connect records

A quick note: is there anything obvious returned by a diff between the
sqlgrey.conf files on the two greylisting servers? You could have
surprising problems if they aren't synchronised properly.

Lionel.


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your
very own Sony(tm)PSP.  Click here to play:
http://sourceforge.net/geronimo.php
_______________________________________________
Sqlgrey-users mailing list
Sql...@li...
https://lists.sourceforge.net/lists/listinfo/sqlgrey-users


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your
very own Sony(tm)PSP.  Click here to play:
http://sourceforge.net/geronimo.php
_______________________________________________
Sqlgrey-users mailing list
Sql...@li...
https://lists.sourceforge.net/lists/listinfo/sqlgrey-users

RE: [Sqlgrey-users] Duplicate connect records

[Steffen P. <swp...@am...>]

Hi Lionel,

I use a shell script using scp to sync the sqlgrey.conf files on both
servers. I just checked them and they match.=20

Steffen=20

-----Original Message-----
From: sql...@li...
[mailto:sql...@li...] On Behalf Of Lionel
Bouton
Sent: Wednesday, September 14, 2005 11:16 AM
To: sql...@li...
Subject: Re: [Sqlgrey-users] Duplicate connect records

A quick note: is there anything obvious returned by a diff between the
sqlgrey.conf files on the two greylisting servers? You could have
surprising problems if they aren't synchronised properly.

Lionel.


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your
very own Sony(tm)PSP.  Click here to play:
http://sourceforge.net/geronimo.php
_______________________________________________
Sqlgrey-users mailing list
Sql...@li...
https://lists.sourceforge.net/lists/listinfo/sqlgrey-users

Re: [Sqlgrey-users] Duplicate connect records

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

A quick note: is there anything obvious returned by a diff between the 
sqlgrey.conf files on the two greylisting servers? You could have 
surprising problems if they aren't synchronised properly.

Lionel.