sqlgrey-users — Users of SQLgrey

Re: [Sqlgrey-users] Recipent Whitelist

[Who K. <qui...@me...>]

If I understand that correctly ( don't get me wrong I know how hard some
of these concepts are to put into words ) it is exactly what I want.

By final recipent I assume you mean something like:

the email address me...@do... is and alias to me...@do...

then if domaintwo.com is opted out, the message to me...@do... would
still be greylisted because sqlgrey wouldn't know that it would 
eventually go
to domaintwo.com. Right?

Thanks,
Jim

Lionel Bouton wrote:

>Who Knows wrote the following on 23.04.2005 23:02 :
>
>  
>
>>While I haven't delved into the code extensively, my initial
>>investigation leads me to beleive their is no facility in sqlgrey to
>>specify specific recipient addresses or domains to bypass greylisting.
>>
>>Am I missing something?
>>    
>>
>
>
>No. You can implement this directly with Postfix though. I've seen it
>discussed on the postfix-users mailing-list recently.
>
>There are plans for an opt-in/opt-out in database though. It may be the
>right time to discuss this.
>
>I plan to add 4 tables to SQLgrey's database:
>optin_rcpt
>optin_domain
>optout_rcpt
>optout_domain
>
>The admin would be able to choose from :
>- current behavior (no optin no optout, everyone is greylisted),
>- optin (an rcpt is greylisted if it is listed in optin_rcpt or its
>domain is in optin_domain and the rcpt isn't in optout_rcpt),
>- optout (opposite behaviour rcpt is greylisted if it is NOT in
>optout_rcpt or the domain is in optout_domain and the rcpt isn't in
>optin_rcpt).
>
>Pay attention to the fact that SQLgrey doesn't see the final recipients
>but only the RCPT TO values, users might be surprised to see some emails
>being greylisted after having opted-out when these are sent to aliases...
>
>Is it something everyone would be ok with ?
>
>If you are, I'll add both this and IPv6 support in the next 1.5.x
>release, which should freeze the database layout for the 1.6.0 release.
>
>Best regards,
>
>Lionel.
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Sqlgrey-users mailing list
>Sql...@li...
>https://lists.sourceforge.net/lists/listinfo/sqlgrey-users
>  
>

Re: [Sqlgrey-users] Recipent Whitelist

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

Who Knows wrote the following on 23.04.2005 23:02 :

> While I haven't delved into the code extensively, my initial
> investigation leads me to beleive their is no facility in sqlgrey to
> specify specific recipient addresses or domains to bypass greylisting.
>
> Am I missing something?


No. You can implement this directly with Postfix though. I've seen it
discussed on the postfix-users mailing-list recently.

There are plans for an opt-in/opt-out in database though. It may be the
right time to discuss this.

I plan to add 4 tables to SQLgrey's database:
optin_rcpt
optin_domain
optout_rcpt
optout_domain

The admin would be able to choose from :
- current behavior (no optin no optout, everyone is greylisted),
- optin (an rcpt is greylisted if it is listed in optin_rcpt or its
domain is in optin_domain and the rcpt isn't in optout_rcpt),
- optout (opposite behaviour rcpt is greylisted if it is NOT in
optout_rcpt or the domain is in optout_domain and the rcpt isn't in
optin_rcpt).

Pay attention to the fact that SQLgrey doesn't see the final recipients
but only the RCPT TO values, users might be surprised to see some emails
being greylisted after having opted-out when these are sent to aliases...

Is it something everyone would be ok with ?

If you are, I'll add both this and IPv6 support in the next 1.5.x
release, which should freeze the database layout for the 1.6.0 release.

Best regards,

Lionel.

[Sqlgrey-users] Recipent Whitelist

[Who K. <qui...@me...>]

While I haven't delved into the code extensively, my initial 
investigation leads me to beleive their is no facility in sqlgrey to 
specify specific recipient addresses or domains to bypass greylisting.

Am I missing something?

Thanks,
Jim

[Sqlgrey-users] (Another) possible bug in sqlgrey ?

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

I also find values such as:

bounce-#-5541b8d889bbaf2de05c02b4a0af204f93174a98-#

in the "sender_name" column of from_awl, for some VERP messages that are=20
received on a regular basis.

I believe such addresses should have been collapsed into:

bounce-#-#-#

...so there may be a bug in the substitution regexp for such cases.

The original corresponding "true" sender localpart for this example was (=
case=20
respected):

bounce-439452-5541B8D889BBAF2DE05C02B4A0AF204F93174A98-439250@...

(Note that the 2 parts that have been correctly substituted were [0-9]+, =
where=20
the part that wasn't substituted was Hex, and the original address was=20
uppercase Hex, where SQLgrey stored it in from_awl as lowercase Hex...)

Cheers.

--=20
Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E
Appel de 200 Informaticiens pour le NON au Trait=E9 Constitutionnel
Europ=E9en: http://www.200informaticiens.ras.eu.org

[Sqlgrey-users] Possible bug in sqlgrey ?

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

Hi there,

I've been wondering for some time if there couldn't be a bug in sqlgrey f=
or=20
"plussed" extension source addresses.

These last days, I see very often VERP addresses from a ML, in a format s=
uch=20
as:

list-name+bounces-123-destination.user=3Dd...@li...=
g

getting greylisted everytime by SQLgrey (and entered in the connect table=
),=20
where I see that the from_awl table actually already contains an entry su=
ch=20
as:

sender_name =3D list-name
sender_domain =3D server.listdomain.org

And this entry gets updated when the mail finally makes it thru.

I have the impression that with such "+"ed addresses, for some reason, th=
e=20
from_awl "sender_domain" gets the sending server name FQDN instead of get=
ting=20
the sender's domain alone.

The connect table, OTOH, seems to get the correct complete sender address=
=20
localpart, and sender domain

I'm not completely sure about this, but I found this weird enough to post=
 this=20
report ;-)

Cheers.

--=20
Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E
Appel de 200 Informaticiens pour le NON au Trait=E9 Constitutionnel
Europ=E9en: http://www.200informaticiens.ras.eu.org

Re: [Sqlgrey-users] SQLgrey and IPv6

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

Allan Joergensen wrote the following on 19.04.2005 10:50 :

> Lionel Bouton wrote, On 25-03-2005 14:26:
>
>> You should use 'greymethod=full' with IPv6 until I figure out the best
>> strategy to implement smart and classc for IPv6.
>
>
> What is the status of IPv6?
>
In the pipe. You can make it work now with a simple VARCHAR column
length modification and by using greymethod=full but it won't be optimal.

Lionel.

Re: [Sqlgrey-users] SQLgrey and IPv6

[Allan J. <al...@no...>]

Lionel Bouton wrote, On 25-03-2005 14:26:

> You should use 'greymethod=full' with IPv6 until I figure out the best
> strategy to implement smart and classc for IPv6.

What is the status of IPv6?

-- 
Allan Joergensen - http://nowhere.dk/
"No matter what they're talking about, they're talking about money."

Re: [Sqlgrey-users] SQLgrey and IPv6

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

I wrote:

>>> "Use of uninitialized value in join or string at
>>> /usr/local/sbin/sqlgrey line 711."
>>
>> If I'm not mistaken it should be harmless (annoying but harmless). It
>> doesn't quit does it ?
>=20
> You're right, it's harmless and SQLgrey doesn't quit.

But the error messages are annoying in the logfile, so I've added a
line to the subroutine:

sub class_c {
    return $_[0] unless $_[0] =3D~ /\./;
    return join('.', (split(/\./, shift))[0..2]);
}

I don't speak perl, so please don't flame me for the un-prettiness. ;-)

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

Re: [Sqlgrey-users] SQLgrey and IPv6

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

Lionel Bouton wrote:

>> "Use of uninitialized value in join or string at
>> /usr/local/sbin/sqlgrey line 711."
>=20
> If I'm not mistaken it should be harmless (annoying but harmless). It
> doesn't quit does it ?

You're right, it's harmless and SQLgrey doesn't quit.

> You should use 'greymethod=3Dfull' with IPv6 until I figure out the best
> strategy to implement smart and classc for IPv6.

/me edits sqlgrey.conf

Thanks!

--=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 25.03.2005 13:12 :

>IPv6 issue:
>
>The subroutine (at appr. line 711 in sqlgrey v1.5.4):
>
>sub class_c {
>    return join('.', (split(/\./, shift))[0..2]);
>}
>
>causes a
>
>"Use of uninitialized value in join or string at
>/usr/local/sbin/sqlgrey line 711."
>
>error message upon IPv6 connects.
>
>  
>

If I'm not mistaken it should be harmless (annoying but harmless). It
doesn't quit does it ? The corresponding class_c output should be
identical to its input, meaning the smart/classc algo will behave in the
same ways than 'full'.
You should use 'greymethod=full' with IPv6 until I figure out the best
strategy to implement smart and classc for IPv6.

Lionel.

Re: [Sqlgrey-users] SQLgrey and IPv6

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

IPv6 issue:

The subroutine (at appr. line 711 in sqlgrey v1.5.4):

sub class_c {
    return join('.', (split(/\./, shift))[0..2]);
}

causes a

"Use of uninitialized value in join or string at
/usr/local/sbin/sqlgrey line 711."

error message upon IPv6 connects.

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

New logging configuration (was Re: [Sqlgrey-users] "Probable spam" log entries)

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

Michael Storz wrote the following on 17.03.2005 12:40 :

>On Wed, 16 Mar 2005, Lionel Bouton wrote:
>
>  
>
>>Funny logging is mentionned now :
>>I'm currently reworking the logging and adding categories in the process
>>so as to allow users to choose what they want to log more precisely.
>>    
>>
>
>Could you describe what the new model of logging looks like? Maybe we'll
>have suggestions what to include based on our needs.
>  
>

Nothing is carved in stone yet, but the idea is to split logging into 
categories. I've made a quick pass on the existing log() statements and 
have identified several preliminary categories:

greylisting: decisions based on greylisting algos
whitelist: decisions based on whitelists
dbaccess: db upgrades, db access errors,
martians: things coming from Postfix we aren't expecting,
mail: mails sent to the administrator,
spam: detected spam attempts
perf: time spent in most intensive operations
system: forks
conf: conf loading/reloading
other: ...

My current plan is to continue using a default loglevel but to allow 
overriding it for each of these categories.

Instead of "debug", "verbose", "normal", "quiet", ...
There will be something like:
default_loglevel = 2
loglevel_override = perf:4,mail:0

with 0:silent -> 4:debug

Lionel.

Re: [Sqlgrey-users] "Probable spam" log entries

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

On Wed, 16 Mar 2005, Lionel Bouton wrote:

> Funny logging is mentionned now :
> I'm currently reworking the logging and adding categories in the process
> so as to allow users to choose what they want to log more precisely.

Could you describe what the new model of logging looks like? Maybe we'll
have suggestions what to include based on our needs.

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] "Probable spam" log entries

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

On Wed, 16 Mar 2005, Lionel Bouton wrote:

> Funny logging is mentionned now :
> I'm currently reworking the logging and adding categories in the process
> so as to allow users to choose what they want to log more precisely.
>

Don't forget to implement logging for the cleanup of from_awl und
domain_awl. I would wish a minimal logging => logging of records deleted
and a maximum logging => number of records and exactly which records were
deleted.

We would use the first information for a graphical representation of
the cleanup of the various tables and would use the second for debugging
purposes.

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] "Probable spam" log entries

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

Morris Jones wrote the following on 16.03.2005 23:19 :

> Michel Bouissou wrote:
>
>> Le Mercredi 16 Mars 2005 22:43, Morris Jones a =E9crit :
>>
>>> Does anyone make use of the "Probable spam: " cleanup report for
>>> anything interesting?
>>
>>
>> I use them for log analysis. Please leave them in ;-)
>
>
> That's interesting enough.  :)
>
> Mojo


Funny logging is mentionned now :
I'm currently reworking the logging and adding categories in the process=20
so as to allow users to choose what they want to log more precisely.

Re: [Sqlgrey-users] "Probable spam" log entries

[Morris J. <mo...@wh...>]

Michel Bouissou wrote:
> Le Mercredi 16 Mars 2005 22:43, Morris Jones a =E9crit :
>=20
>>Does anyone make use of the "Probable spam: " cleanup report for
>>anything interesting?
>=20
> I use them for log analysis. Please leave them in ;-)

That's interesting enough.  :)

Mojo
--=20
Morris Jones
Monrovia, CA
http://www.whiteoaks.com
Old Town Astronomers: http://www.otastro.org

Re: [Sqlgrey-users] "Probable spam" log entries

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

Le Mercredi 16 Mars 2005 22:43, Morris Jones a =E9crit :
>
> Does anyone make use of the "Probable spam: " cleanup report for
> anything interesting?

I use them for log analysis. Please leave them in ;-)

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

[Sqlgrey-users] "Probable spam" log entries

[Morris J. <mo...@wh...>]

Does anyone make use of the "Probable spam: " cleanup report for 
anything interesting?

Mojo
-- 
Morris Jones
Monrovia, CA
http://www.whiteoaks.com
Old Town Astronomers: http://www.otastro.org

Re: [Sqlgrey-users] Got it to work and then MailScanner...

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

Craig White wrote the following on 16.03.2005 03:15 :

>Evidently, MailScanner interferes...
>
>It launches and controls postfix process and sqlgrey - though running is
>never considered.
>
>IE - if I turn off MailScanner and run Postfix, sqlgrey runs
>
>Anybody using MailScanner and sqlgrey together with Postfix?
>  
>

I may be mistaken, but IIRC MailScanner uses tricks to interfere with 
the normal Postfix queueing system and is regularly the source of nasty 
problems... Postfix developpers advise not to use it.

For amavis (or amavisd-new): did you manage to make it work without 
SQLgrey in the loop ?

Lionel.

[Sqlgrey-users] Got it to work and then MailScanner...

[Craig W. <cra...@az...>]

Evidently, MailScanner interferes...

It launches and controls postfix process and sqlgrey - though running is
never considered.

IE - if I turn off MailScanner and run Postfix, sqlgrey runs

Anybody using MailScanner and sqlgrey together with Postfix?

Anybody using Amavis and sqlgrey together with Postfix?

Any clues on how I might get this done?

Craig

Re: [Sqlgrey-users] update_sqlgrey_config

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

Michel Bouissou wrote the following on 15.03.2005 11:24 :

>Hi there,
>
>I installed sqlgrey-1.5.4-1 yesterday evening (Mandrake RPM available from
>http://www.bouissou.net/sqlgrey/ ), and I find the following in my update
>log this morning.
>
>I had already noticed this every time I installed a new version lately :
>There seems to be a newline character difference  between the regexp file
>provided in the tarball and the one present on the update server.
>
>I don't know if this matters at all, but just in case...
>  
>

It doesn't matter. It just means I probably messed up the original by 
editing it with an editor which allows a single line withour CR and then 
vi. The line is 'chomp'ed by SQLgrey anyway: the newline is stripped if 
present.
I'll sync the file for the next release.

Lionel.

Re: [Sqlgrey-users] getting configuration error

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

Craig White wrote the following on 15.03.2005 09:52 :

>tail -n 5 /etc/postfix/main.cf
>#smtpd_recipient_restrictions =
>#              ...
>#              reject_unauth_destination
>#              check_policy_service inet:127.0.0.1:2501
>
>(of course when comments are removed is when the problem starts)
>  
>

Just a guess: if you really have the empty line with three dots, your 
symptom is normal. "..." was meant to mean "the rules you already have 
set up".

Lionel.

[Sqlgrey-users] update_sqlgrey_config

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

Hi there,

I installed sqlgrey-1.5.4-1 yesterday evening (Mandrake RPM available fro=
m
http://www.bouissou.net/sqlgrey/ ), and I find the following in my update
log this morning.

I had already noticed this every time I installed a new version lately :
There seems to be a newline character difference  between the regexp file
provided in the tarball and the one present on the update server.

I don't know if this matters at all, but just in case...

---------------------------- Message original ---------------------------=
-
Objet:   Cron <root@totor> nice -n 15 run-parts /etc/cron.daily
De:      "Cron Daemon" <ro...@bo...>
Date:    Mar 15 mars 2005 4:35
=C0:       ro...@bo...
-------------------------------------------------------------------------=
-

updating /etc/sqlgrey/smtp_server.regexp:
--- /etc/sqlgrey/smtp_server.regexp	2005-03-15 00:33:39.000000000 +0100
+++ smtp_server.regexp	2005-03-02 01:29:45.000000000 +0100
@@ -1 +1 @@
-^(.+[._-])*(apache|bounce|bulk|delay|d?ns|external|extranet|filter|firew=
all|forward|gateway|gw|m?liste?s?|(bulk|dead|mass|send|[eqw])?mail(er)?|e=
?mail(agent|host|hub|scan(ner)?)|messagerie|mta|v?mx|out(bound)?|pop|post=
fix|w?proxy|rela(is|y)|serveu?r|smarthost|v?smtp|web|www)(gate|mail|mx|po=
ol|out|server)?[0-9]*[._-]
\ No newline at end of file
+^(.+[._-])*(apache|bounce|bulk|delay|d?ns|external|extranet|filter|firew=
all|forward|gateway|gw|m?liste?s?|(bulk|dead|mass|send|[eqw])?mail(er)?|e=
?mail(agent|host|hub|scan(ner)?)|messagerie|mta|v?mx|out(bound)?|pop|post=
fix|w?proxy|rela(is|y)|serveu?r|smarthost|v?smtp|web|www)(gate|mail|mx|po=
ol|out|server)?[0-9]*[._-]

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

[Sqlgrey-users] getting configuration error

[Craig W. <cra...@az...>]

# cat 22.
Return-Path: <dou...@sr...>
Received: from srv1.myhomelenders.net ([unix socket])
         by srv1.myhomelenders.net (Cyrus v2.2.12-Invoca-RPM-2.2.12-1)
with LMTPA;
         Tue, 15 Mar 2005 01:26:32 -0700
X-Sieve: CMU Sieve 2.2
Received: by srv1.myhomelenders.net (Postfix)
        id BB241F8662; Tue, 15 Mar 2005 01:26:31 -0700 (MST)
Date: Tue, 15 Mar 2005 01:26:31 -0700 (MST)
From: MAI...@sr... (Mail Delivery System)
To: pos...@my... (Postmaster)
Subject: Postfix SMTP server: errors from unknown[221.158.158.106]
Message-Id: <200...@sr...>

Transcript of session follows.

 Out: 220 srv1.myhomelenders.net ESMTP Postfix
 In:  HELO 67.89.141.130
 Out: 250 srv1.myhomelenders.net
 In:  MAIL FROM: <rw...@rs...>
 Out: 250 Ok
 In:  RCPT TO: <de...@ca...>
 Out: 451 Server configuration error
 In:  RCPT TO: <al...@ca...>
 Out: 451 Server configuration error
 In:  QUIT
 Out: 221 Bye

---
# rpm -qa postfix
postfix-2.1.5-2.3.RHEL4.1

tail -n 5 /etc/postfix/main.cf
#smtpd_recipient_restrictions =
#              ...
#              reject_unauth_destination
#              check_policy_service inet:127.0.0.1:2501

(of course when comments are removed is when the problem starts)

[root@srv1 root]# printf 'select * from connect;\n' |mysql sqlgrey
[root@srv1 root]# printf 'select * from domain_awl;\n' |mysql sqlgrey
[root@srv1 root]# printf 'select * from from_awl;\n' |mysql sqlgrey
[root@srv1 root]# printf 'select * from config;\n' |mysql sqlgrey
parameter       value
version 1

How do I fix this?

Craig

Re: [Sqlgrey-users] Re: Is clients_fqdn_whitelist.local still being used?

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

Lionel Bouton wrote:

> Found it (perl regexp compilation mixup, nullify the private connection
> detection code of the new smartc too). Packaging 1.5.4 with the fixes now=
.

/me rushes to install 1.5.4

:-),

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