sqlgrey-users

[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:

lis...@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

[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

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

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

Michel Bouissou wrote the following on 23.04.2005 20:30 :

>I also find values such as:
>
>bounce-#-5541b8d889bbaf2de05c02b4a0af204f93174a98-#
>
>in the "sender_name" column of from_awl, for some VERP messages that are 
>received on a regular basis.
>
>I believe such addresses should have been collapsed into:
>
>bounce-#-#-#
>  
>

I believed the same too :-/

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

BTW, I just found out that we were matching "SRS" in the
normalize_sender, but it is called after lowercasing the whole string...
I've neither seen an SRS email, but I think the current code doesn't
match. I lowercased the corresponding regexp in my tree.

>The original corresponding "true" sender localpart for this example was (case 
>respected):
>
>bounce-439452-5541B8D889BBAF2DE05C02B4A0AF204F93174A98-439250@...
>
>  
>

I'm adding a while loop to call the regexp until the string doesn't
change anymore, this should strip each hex sequence one by one. I'm
looking at the s/orig/dest/g syntax to see the problem (might come from
variable usage in dest: $1#$2).

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

SQLgrey always lowercases the e-mail adresses.

Lionel.

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

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

Le Dimanche 24 Avril 2005 22:05, Lionel Bouton a =E9crit :
>
> BTW, I just found out that we were matching "SRS" in the
> normalize_sender, but it is called after lowercasing the whole string..=
.
> I've neither seen an SRS email, but I think the current code doesn't
> match. I lowercased the corresponding regexp in my tree.

If you wish, I can create an alias for you at my domain, that would be=20
forwarded and SRS'd to any address of your choice. Email forwarded thru t=
his=20
alias would be SRS'd, so you could check how it looks like by yourself.
Please tell me by private mail if you would be interested.

> >The original corresponding "true" sender localpart for this example wa=
s
> > (case respected):
> >
> >bounce-439452-5541B8D889BBAF2DE05C02B4A0AF204F93174A98-439250@...
>
> I'm adding a while loop to call the regexp until the string doesn't
> change anymore, this should strip each hex sequence one by one. I'm
> looking at the s/orig/dest/g syntax to see the problem (might come from
> variable usage in dest: $1#$2).

I believe that you are correct.

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] Possible bug in sqlgrey ?

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

Michel Bouissou wrote the following on 23.04.2005 20:07 :

>Hi there,
>
>I've been wondering for some time if there couldn't be a bug in sqlgrey for 
>"plussed" extension source addresses.
>
>These last days, I see very often VERP addresses from a ML, in a format such 
>as:
>
>lis...@li...
>
>getting greylisted everytime by SQLgrey (and entered in the connect table), 
>where I see that the from_awl table actually already contains an entry such 
>as:
>
>sender_name = list-name
>sender_domain = 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, the 
>from_awl "sender_domain" gets the sending server name FQDN instead of getting 
>the sender's domain alone.
>
>  
>

I've looked at the code and AFAIKT nowhere are the $fqdn and
$sender_domain mixed up. What could happen is that some misconfigured
server could change the MAIL FROM: on retries. This could explain what
you are witnessing. Could you have a look into Postfix's logs?

If it's the case, this would be a good candidate to the whitelists...

Lionel

Re: [Sqlgrey-users] Possible bug in sqlgrey ?

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

Le Dimanche 24 Avril 2005 22:05, Lionel Bouton a =E9crit :
>
> >I have the impression that with such "+"ed addresses, for some reason,=
 the
> >from_awl "sender_domain" gets the sending server name FQDN instead of
> > getting the sender's domain alone.
>
> I've looked at the code and AFAIKT nowhere are the $fqdn and
> $sender_domain mixed up. What could happen is that some misconfigured
> server could change the MAIL FROM: on retries. This could explain what
> you are witnessing. Could you have a look into Postfix's logs?

I've checked both my Postfix logs (quickly, I didn't have much time) and =
the=20
code, and so far I don't understand clearly what happens on this respect.=
 It=20
is quite possible that I have reported a non-existing problem ;-) but my=20
server being only secondary on the concerned receiving domain, I have to =
take=20
a look at what happens at the primary itself.
Anyway, as the primary also uses SQLgrey, the concerned ML addresses shou=
ld=20
already be whitelisted by SQLgrey at the primary, so I shouldn't get all=20
these connections and greylist them. There's something puzzling me there.

> If it's the case, this would be a good candidate to the whitelists...

This concerns all of the "gentoo" mailing-lists, coming from server=20
lists.gentoo.org[140.105.134.102]...

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