sqlgrey-users — Users of SQLgrey

Re: [Sqlgrey-users] More on sqlgrey stop/recover issue

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

Andrew Diederich wrote the following on 18.12.2006 21:14 :
> Dec 18 12:32:43 tango sqlgrey: dbaccess: warning: couldn't do query: UP=
DATE from_awl SET last_seen =3D NOW(), first_seen =3D first_seen WHERE se=
nder_name =3D 'man=C3=83=C5=A1genervy' AND sender_domain =3D 'abyss.wesn.=
sun.com' AND src =3D '81.215.189.168': ERROR:  invalid byte sequence for =
encoding "UNICODE": 0xe86765 , reconnecting to DB
>  =20

Hum, did you try to use a database with ASCII instead of UNICODE?=20
SQLgrey doesn't try to speak utf-8 with the database but only pure=20
ASCII. If you receive adresses with characters outside the utf-8 space,=20
this behavior is expected with a UNICODE database.

Nothing to do with unicode domain names (these ones are encoded in ASCII=20
anyway, so Postfix and SQLgrey don't need to be aware of them). You=20
can't configure Postfix easily to solve this and to solve it in SQLgrey,=20
we would have to make it aware of the database encoding and call iconv=20
to make sure everything fits, assuming the original encoding is always=20
ISO-8859-1 for the Return-Path.

ASCII at the database level is your best bet, you should dump your DB,=20
create another one with ASCII encoding, restore the original DB in the=20
new one, change SQLgrey's database in sqlgrey.conf and restart SQLgrey.

Lionel

[Sqlgrey-users] More on sqlgrey stop/recover issue

[Andrew D. <and...@gm...>]

Hello SQLgrey,

I've run into quite a few instances over the last month or so where
SQLgrey gets a "SQLgrey database error" and then recovers.  I think it
has to do with unicode domain names.  I started running SQLgrey with
more logging, and here's a snippet for when things go badly:

Dec 18 12:32:41 tango postfix/smtpd[10133]: connect from unknown[81.215.189=
.168]
Dec 18 12:32:42 tango sqlgrey: 2006/12/18-12:32:42 CONNECT TCP Peer: "127.0=
.0.1:54494" Local: "127.0.0.1:2501"
Dec 18 12:32:42 tango sqlgrey: optin: greylisting active for
jb...@ex...
Dec 18 12:32:42 tango sqlgrey: grey: unknown RDNS: 81.215.189.168
Dec 18 12:32:42 tango sqlgrey: warning: Use of uninitialized value in conca=
tenation (.) or string at /usr/sbin/sqlgrey line 1062.
Dec 18 12:32:42 tango sqlgrey: dbaccess: error: couldn't access from_awl ta=
ble:=20
Dec 18 12:32:43 tango sqlgrey: grey: from awl match: updating 81.215.189.16=
8(81.215.189.168), man...@ab...(man=C3=A8gednervy@a=
byss.wesn.sun.com)
Dec 18 12:32:43 tango sqlgrey: dbaccess: warning: couldn't do query: UPDATE=
 from_awl SET last_seen =3D NOW(), first_seen =3D first_seen WHERE sender_n=
ame =3D 'man=C3=A8genervy' AND sender_domain =3D 'abyss.wesn.sun.com' AND s=
rc =3D '81.215.189.168': ERROR:  invalid byte sequence for encoding "UNICOD=
E": 0xe86765 , reconnecting to DB
Dec 18 12:32:43 tango postfix/pickup[9793]: 04D7E1A6BD: uid=3D1004 from=3D<=
sqlgrey>

That line in SQLgrey is a log error:
 $self->mylog('dbaccess', 0, "error: couldn't access $from_awl table: $DBI:=
:errstr");

and the whole function is:
## Match connections to AWLs ##

sub is_in_from_awl {
    my ($self, $sender_name, $sender_domain, $host) =3D @_;

    # last_seen less than $self->{sqlgrey}{awl_age} days ago
    my $sth =3D $self->prepare("SELECT 1 FROM $from_awl " .
                 'WHERE sender_name =3D ? ' .
                 'AND sender_domain =3D ? ' .
                 'AND src =3D ? ' .
                 'AND last_seen > ' .
                 $self->past_tstamp($self->{sqlgrey}{awl_age},
                        'DAY')
                );
    if (!defined $sth or !$sth->execute($sender_name, $sender_domain, $host=
)) {
    $self->db_unavailable();
    $self->mylog('dbaccess', 0, "error: couldn't access $from_awl table: $D=
BI::errstr");
        return 1; # in doubt, accept
    } else {
    $self->db_available();
    }
    my $result =3D $sth->fetchall_arrayref();
    if ($#$result !=3D 0) {
    return 0; # not a single entry
    } else {
    return 1; # one single entry (no multiple entries by design)
    }
}


Is there anything I can do in either SQLgrey or postfix to stop this
from happening?  As far as I can tell it always reconnects right away,
but it is a little concerning.

--=20
Best regards,
 Andrew

[Sqlgrey-users] qlgrey stops after a while - solved

[Michael Z. <zi...@ve...>]

Just to let you all know:

The problem disappeared after starting sqlgrey correctly
with the -d (deamonize) flag.

Have a nice day, thanks for your help.

Michael

Re: [Sqlgrey-users] sqlgrey stops after a while

[Dan F. <da...@ha...>]

Lionel Bouton wrote:
> Michael Zimmermann wrote the following on 30.11.2006 23:49 :
>   
>> after running a while sqlgrey stops working. The logs show, that it
>> restarted, but it's
>> port is closed after the restart.
>>     
>
> It could be the old sqlgrey process still living and bound to the socket
> when the new one comes up (the underlying Net::Server::Multiplex library
> has already demonstrated this behaviour on my systems). My solution was to :
> 1/ add a long enough sleep between the TERM signal (sqlgrey -k or
> killall sqlgrey for example) and the restart.
>   
My other policy daemon actually did this from time to time, though i 
dont recall sqlgrey doing it.
My solution was first the "sleep 2" thingie, but i then solved it by 
adding "Reuse => 1" to the creation of Net::Server. It seemed that the 
socket wasnt released fast enough and adding "Reuse" should allow it 
to... Well.. Reuse the socket ;)

Ive also had a similar problem with postgrey back in the days, which was 
due to the cleanup running for to long time which made postfix believe 
it was offline. (though i dont remember if the socket actually died).

If Michaels problem persists, socket "Reuse" might be worth a try.

- Dan Faerch

Re: [Sqlgrey-users] sqlgrey stops after a while

[Michael Z. <zi...@ve...>]

Hi Lionel,

thanks for your help.

> Anyway, why do you need to restart SQLgrey? There are reasons such as
> DBD-driver leaks with some versions of the PostgreSQL DBD driver for
> example, but they should be exceptions.
>   

I didn't restart it. Sqlgrey did that on itself. I just observed that it 
did not do it's job
after some time, recognized that port 2501 was closed , so I set a 
watchdog on
localhost:2501 and checked what had happened, when the watchdog barked.

But perhaps that problem was a consequence of not starting sqlgrey as a 
daemon.
I will see and come back with the results, after it runs a day or two 
started
correctly with the -d flag. :)

greetings
Michael

Re: [Sqlgrey-users] sqlgrey stops after a while

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

Michael Zimmermann wrote the following on 30.11.2006 23:49 :
> Dear list,
>
> after running a while sqlgrey stops working. The logs show, that it
> restarted, but it's
> port is closed after the restart.

It could be the old sqlgrey process still living and bound to the socket
when the new one comes up (the underlying Net::Server::Multiplex library
has already demonstrated this behaviour on my systems). My solution was to :
1/ add a long enough sleep between the TERM signal (sqlgrey -k or
killall sqlgrey for example) and the restart.
2/ use Nagios to monitor the port (check_tcp) and be warned if it goes down.


>
> X-Greylist: delayed 00:05:05 by SQLgrey-1.7.4

Good I know the version -:)

> Use of uninitialized value in unlink at /usr/sbin/sqlgrey line 2577.

Odd : it seems the pidfile location is undefined when trying to kill the
daemon.

>
> The sqlgrey is just started manually via a  
>    # nohup sqlgrey &
>

Ok I know why SQLgrey doesn't find a pidfile: it doesn't know it is
running as a daemon. You should start it with 'sqlgrey -d' and kill it
with 'sqlgrey -k' both as root (they need read/write access to
/var/run/sqlgrey.pid and change to sqlgrey's uid later anyway).

> or am I wrong about that, and the sqlgrey needs to be entered into the
> master.cf to be started as a postfix-service?
>

No, it doesn't support running from master.cf (until someone codes the
support for this).

To sum up :
- first try the 'sqlgrey -d' / 'sqlgrey -k' start/stop method,
- then if you still have problems when restarting SQLgrey, make a short
pause (one second should be enough, increase if you still have problems)
between the stop and the start.

Anyway, why do you need to restart SQLgrey? There are reasons such as
DBD-driver leaks with some versions of the PostgreSQL DBD driver for
example, but they should be exceptions.

Lionel.

Re: [Sqlgrey-users] Non retrying servers

[<tom...@fi...>]

On 2006-11-30 22:51:35 +0100, Lionel Bouton 
<lio...@bo...> said:

> > ahd1014.activehost.com [69.89.227.49]
> >
> 
> That
> 's a suspicious looking little box... This is not the MX for the
> domain (although it isn't uncommon to have differ
> ent outgoing servers,
> it's rather uncommon that they have
>  such anonymous names). A bunch of
> dns lookups in the sam
> e class C shows several other
> ahd10??.activehost.com name
> s scattered across the class C. Does this
> system really s
> end legitimate mails and if affirmative, from which domai
> ns?

Namecheap, a popular domain registar (http://www.namecheap.com/). I 
only noticed when one of my domains nearly expired when I didn't get a 
renewal notice.

I have them in my whitelist now, and here is recent log.

Nov 27 06:25:48 ra postfix/smtpd[24032]: connect from 
ahd1014.activehost.com[69.89.227.49]
Nov 27 06:25:49 ra sqlgrey: whitelist: ren...@na..., 
69.89.227.49(ahd1014.activehost.com)
-> tom...@fi...
Nov 27 06:25:49 ra postfix/smtpd[24032]: 2B2F78C020: 
client=ahd1014.activehost.com[69.89.227.49]
Nov 27 06:25:49 ra postfix/cleanup[24034]: 2B2F78C020: 
message-id=<20061127-00210389-9a4-0@IPDMDZ000
2MIA>
Nov 27 06:25:49 ra postfix/qmgr[14772]: 2B2F78C020: 
from=<ren...@na...>, size=1805, nrcpt=
1 (queue active)

[cut]


I guess you could try it by registering a account with namecheap and 
wait for the confirmation mail, but I doubt it they fixed it.

Tomislav

[Sqlgrey-users] sqlgrey stops after a while

[Michael Z. <zi...@ve...>]

Dear list,

after running a while sqlgrey stops working. 
The logs show, that it restarted, but it's
port is closed after the restart.

Running it with log-level 4 showed:

optin: greylisting active for zi...@ve...
grey: identified dynamic pattern (last IP byte): 
12-226-48-61.client.mchsi.com, 12.226.48.61: Using full IP.
grey: reconnect ok: 12.226.48.61(12.226.48.61), jo...@pi... -> 
zi...@ve... (00:05:05)
grey: from awl: 12.226.48.61, jo...@pi... added
request: ccert_fingerprint= ccert_issuer= ccert_subject= 
client_address=12.226.48.61 client_name=12-226-48-61.client.mchsi.com 
helo_name=friend instance=472.456e1830.0 protocol_name=ESMTP 
protocol_state=RCPT queue_id= rec...@ve... 
request=smtpd_access_policy sasl_method= sasl_sender= sasl_username= 
sen...@pi... size=0 action=PREPEND X-Greylist: delayed 
00:05:05 by SQLgrey-1.7.4
2006/11/30-00:32:06 Server closing!
2006/11/30-00:32:06 HUP'ing server
2006/11/30-00:32:07 sqlgrey (type Net::Server::Multiplex) starting! 
pid(30268)
Use of uninitialized value in unlink at /usr/sbin/sqlgrey line 2577.
Binding open file descriptors
Binding to TCP port 2501 on host localhost
Setting gid to "66 66"
other: Initial cleanup
perf: spent 0s cleaning: from_awl (0) domain_awl (0) connect (0)
-- after that sqlgrey's port is closed --

As the lines before the final stop + (unsuccessful) restart don't have
a timestamp, I am not sure, that the last action did really occur just
before the shutdown+restart. Hence the reason for the shutdown could
well be something, which is not connected with the input (but perhaps
with a timeout on the postfix side?).


The sqlgrey is just started manually via a   

    # nohup sqlgrey &

or am I wrong about that, and the sqlgrey needs to be entered into the
master.cf to be started as a postfix-service?


Thanks for your ideas about that situation
Michael

Re: [Sqlgrey-users] Non retrying servers

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

Tomislav Filip=C4=8Di=C4=87 wrote the following on 30.11.2006 19:15 :
> On 2006-11-30 14:10:50 +0100, Lionel Bouton=20
> <lio...@bo...> said:
>
>  =20
>> I've received a notification for the two following servers.
>>
>> mxs1.siemens.at (194.138.12.131)
>> mxs2.siemens.at (194.138.12.133)
>>
>> Apparently they don't retry. Can anyone confirm this? At least they=20
>> seem legitimate. So baring any problem, I'll add them in the whitelist=
s=20
>> tomorrow.
>>    =20
>
>
> ahd1014.activehost.com [69.89.227.49]
>  =20

That's a suspicious looking little box... This is not the MX for the
domain (although it isn't uncommon to have different outgoing servers,
it's rather uncommon that they have such anonymous names). A bunch of
dns lookups in the same class C shows several other
ahd10??.activehost.com names scattered across the class C. Does this
system really send legitimate mails and if affirmative, from which domain=
s?

Lionel

Re: [Sqlgrey-users] Non retrying servers

[<tom...@fi...>]

On 2006-11-30 14:10:50 +0100, Lionel Bouton 
<lio...@bo...> said:

> I've received a notification for the two following servers.
> 
> mxs1.siemens.at (194.138.12.131)
> mxs2.siemens.at (194.138.12.133)
> 
> Apparently they don't retry. Can anyone confirm this? At least they 
> seem legitimate. So baring any problem, I'll add them in the whitelists 
> tomorrow.


ahd1014.activehost.com [69.89.227.49]

No retry. As they are a hosting company I presume they use multiple 
SMTP servers.

Re: [Sqlgrey-users] Non retrying servers

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

On Thu, 30 Nov 2006, Lionel Bouton wrote:

> I've received a notification for the two following servers.
>
> mxs1.siemens.at (194.138.12.131)
> mxs2.siemens.at (194.138.12.133)
>

At least they are in my domain_awl:

+---------------+----------------+---------------------+---------------------+
| sender_domain | src            | first_seen          | last_seen           |
+---------------+----------------+---------------------+---------------------+
| siemens.com   | 194.138.12.131 | 2006-01-16 16:17:12 | 2006-11-29 15:08:34 |
| siemens.com   | 194.138.12.133 | 2005-10-12 09:00:21 | 2006-11-29 10:48:59 |
+---------------+----------------+---------------------+---------------------+

And they use sendmail:

telnet 194.138.12.131 25
Trying 194.138.12.131...
Connected to 194.138.12.131.
Escape character is '^]'.
220 atvies1zqx.siemens.at ESMTP MTA ready at Thu, 30 Nov 2006 14:50:32 +0100
help
214-2.0.0 This is sendmail version 8.13.1
214-2.0.0 Topics:
214-2.0.0       HELO    EHLO    MAIL    RCPT    DATA
214-2.0.0       RSET    NOOP    QUIT    HELP    VRFY
214-2.0.0       EXPN    VERB    ETRN    DSN     AUTH
214-2.0.0       STARTTLS
214-2.0.0 For more info use "HELP <topic>".
214-2.0.0 To report bugs in the implementation send email to
214-2.0.0       sen...@se....
214-2.0.0 For local information send email to Postmaster at your site.
214 2.0.0 End of HELP info

Therefore I assume they retry.

> Apparently they don't retry. Can anyone confirm this? At least they seem
> legitimate. So baring any problem, I'll add them in the whitelists tomorrow.
>
> Lionel.
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Sqlgrey-users mailing list
> Sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlgrey-users
>

Michael Storz
--
======================================================
Leibniz-Rechenzentrum      |    <mailto:St...@lr...>
Boltzmannstr. 1            |    Fax: +49 89 35831-9700
85748 Garching / Germany   |    Tel: +49 89 35831-8840
======================================================

[Sqlgrey-users] Non retrying servers

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

I've received a notification for the two following servers.

mxs1.siemens.at (194.138.12.131)
mxs2.siemens.at (194.138.12.133)

Apparently they don't retry. Can anyone confirm this? At least they seem 
legitimate. So baring any problem, I'll add them in the whitelists tomorrow.

Lionel.

Re: [Sqlgrey-users] updated spec file

[Bob T. <ta...@re...>]

Urban, Frank wrote:

> You forgot Debian

ftp://ftp.real-time.com/linux/real-time/pool/main/s/sqlobject

Or add to your apt sources list

deb ftp://ftp.real-time.com/linux/real-time sid custom main contrib non-free

OR

deb ftp://ftp.real-time.com/linux/real-time etch custom main contrib
non-free

OR

deb ftp://ftp.real-time.com/linux/real-time sarge custom main contrib
non-free

% sudo apt-get update
% sudo apt-get install sqlgrey

lintian and linda complain on a couple policy things.

I'll put up a bzr repo of the debian directory over the next couple of days.

-- 
Bob Tanner <ta...@re...>          | Phone : (952)943-8700
http://www.real-time.com, Minnesota, Linux | Fax   : (952)943-8500
Key fingerprint = AB15 0BDF BCDE 4369 5B42  1973 7CF1 A709 2CC1 B288

Re: [Sqlgrey-users] updated spec file

[Dan F. <da...@ha...>]

Lionel Bouton wrote:
> The only distribution I've access to are RedHat/Fedora based. Could
> people test it on Trustix/Mandriva/Suse (and other RPM based
> distributions I forgot)? I'd like to see it tested a little more before
> being pushed to the CVS server.
>
> Lionel
Ah.. RPM.. Thats why i  couldnt figure out what the file was for ;).. 
(Debian user).
- Dan

Re: [Sqlgrey-users] updated spec file

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

Urban, Frank wrote the following on 22.11.2006 07:23 :
>  
>   
>> The only distribution I've access to are RedHat/Fedora based. 
>> Could people test it on Trustix/Mandriva/Suse (and other RPM 
>> based distributions I forgot)? I'd like to see it tested a 
>> little more before being pushed to the CVS server.
>>
>>     
> You forgot Debian
>   

Never (I'm a Gentoo user but consider Debian with respect and even
advocate its use for a lot of usage patterns). But testing a RPM spec
file on Debian, you know...

Lionel

Re: [Sqlgrey-users] updated spec file

[Urban, F. <Fra...@co...>]

 
> 
> The only distribution I've access to are RedHat/Fedora based. 
> Could people test it on Trustix/Mandriva/Suse (and other RPM 
> based distributions I forgot)? I'd like to see it tested a 
> little more before being pushed to the CVS server.
> 
You forgot Debian
I can help with Suse if there is nobody else

Frank

Re: [Sqlgrey-users] updated spec file

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

dal...@be... wrote the following on 21.11.2006 02:46 :
> I'd like to offer this version of a spec file for inclusion in sqlgrey.
>
> I made a few changes such including:
>
>  Adding the missing discrimintation.regexp to %files.
>  Identifying all the configs as such.
>  Using macros rather than paths where possible.
>  Call chkconfig on install and uninstall.
>  Identify /etc/sqlgrey/README as a %doc.
>

The only distribution I've access to are RedHat/Fedora based. Could
people test it on Trustix/Mandriva/Suse (and other RPM based
distributions I forgot)? I'd like to see it tested a little more before
being pushed to the CVS server.

Lionel

[Sqlgrey-users] updated spec file

[<dal...@be...>]

I'd like to offer this version of a spec file for inclusion in sqlgrey.

I made a few changes such including:

  Adding the missing discrimintation.regexp to %files.
  Identifying all the configs as such.
  Using macros rather than paths where possible.
  Call chkconfig on install and uninstall.
  Identify /etc/sqlgrey/README as a %doc.

I would have defined the init dir using a macro as below but the Makefile
uses /etc/init.d which is actually a symlink to /etc/rc.d/init.d.
I would like to suggest changing the Makefile to usr /etc/rc.d/init.d for 
at least redhat. I'm not familiar with Gentoo or Debian.

  # expands to /etc/rc.d/init.d, but Makefile uses /etc/init.d
  #%{_initrddir}/%{name}
  /etc/init.d/%{name}

Tested on Fedora Core 5.
-- 
http://bewley.net/

Re: [Sqlgrey-users] Future of sqlgrey ???

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

Michael Storz wrote the following on 17.11.2006 08:56 :
> Hi Lionel,
>
> since you are again answering questions on the list, I would like to ask
> you the question about the future of Sqlgrey.
>
> Will there be a further developement of Sqlgrey or do we have to continue
> to hack Sqlgrey for the features we want to have?
>   

One could become a SQLgrey developer too :-) This is already the case
for Dan Faerch who released 1.7.4. If you want to, just tell me and I'll
give you write access to the CVS.
The rules are simple: I've not much time for 1.7.x so anything 1.7 is
your call. I may help stabilize and polish 1.7 when you plan to release
a stable 1.8.x.
1.6.x is my territory :-) I feel responsible for its stability and will
patch it if necessary. I maintain the dynamic config repository where
whitelists and (non)smtp server regexps are stored but if you need to
add things to the repository and I'm not responsive enough you can
always change the default base URL and maintain your own.

> In the meantime our version of Sqlgrey has a lot of changes. A simple diff
> of sqlgrey-1.7.4 and our version produces 3000+ lines. We have new
> fields in the table entries, we have additional tables, different logging,
> have changed the internal coding how the tables are accessed to get
> consistent behavior and a lot more minor changes.
>
> I am also interested to incorporate the changes Bob has made, to get
> Sqlgrey running in taint-mode, using a module for the configuration etc.
>
> So, is the project dead, just waiting for the end of the greylisting area?
>   

Not dead, only sleeping and waiting for someone to wake it :-)

Lionel

Re: [Sqlgrey-users] admin_mail

[Kasey S. <ksp...@as...>]

Thanks.  It seems to work. :)

On Nov 20, 2006, at 2:10 PM, Internet Helpdesk wrote:

> Kasey Speakman wrote:
>> Can I specify multiple email addresses in the field admin_mail
>> (probably separated by a comma) in the sqlgrey.conf file?
>>
> I think I asked the same question, once upon a time.
>
> Yes, comma separated no spaces.
>
> -Troy
>
> --  
>
>
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Sqlgrey-users mailing list
> Sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlgrey-users
>
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>

Re: [Sqlgrey-users] admin_mail

[Internet H. <hel...@wc...>]

Kasey Speakman wrote:
> Can I specify multiple email addresses in the field admin_mail  
> (probably separated by a comma) in the sqlgrey.conf file?
>   
I think I asked the same question, once upon a time.

Yes, comma separated no spaces.

-Troy

-- 

[Sqlgrey-users] admin_mail

[Kasey S. <ksp...@as...>]

Can I specify multiple email addresses in the field admin_mail  
(probably separated by a comma) in the sqlgrey.conf file?

Re: [Sqlgrey-users] flagged as spam... what happens?

[Kasey S. <ksp...@as...>]

Ah, ok.  That's what I thought, but then I didn't see any retries  
after that, so I didn't know if it got rejected.

Thanks again,

Kasey

On Nov 17, 2006, at 4:12 PM, Daniel J McDonald wrote:

> On Fri, 2006-11-17 at 16:08 -0600, Kasey Speakman wrote:
>> I see entries in the log that say... sqlgrey: spam: ...
>>
>> What happens to them?  Do they get rejected flat out?
>
> The entries are removed from the connection table.
>
> If the client were to retry to send the message again, it would go
> through the same 5 minute day as if it were a new client.
>
>
>
> -- 
> Daniel J McDonald, CCIE # 2495, CISSP # 78281, CNX
> Austin Energy
> http://www.austinenergy.com
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Sqlgrey-users mailing list
> Sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlgrey-users
>
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>

Re: [Sqlgrey-users] flagged as spam... what happens?

[Daniel J M. <dan...@au...>]

On Fri, 2006-11-17 at 16:08 -0600, Kasey Speakman wrote:
> I see entries in the log that say... sqlgrey: spam: ...
> 
> What happens to them?  Do they get rejected flat out?

The entries are removed from the connection table.

If the client were to retry to send the message again, it would go
through the same 5 minute day as if it were a new client.



-- 
Daniel J McDonald, CCIE # 2495, CISSP # 78281, CNX
Austin Energy
http://www.austinenergy.com

[Sqlgrey-users] flagged as spam... what happens?

[Kasey S. <ksp...@as...>]

I see entries in the log that say... sqlgrey: spam: ...

What happens to them?  Do they get rejected flat out?

Kasey