From: Klaus A. S. <kse...@gm...> - 2005-03-11 12:58:16
|
I'm running SQLgrey 1.5.1, and I wonder if the clients_fqdn_whitelist.local file is still being taken into account.=20 I have, among other entries, in the file: # GMX /^(mail|mx0|pop|imap)\.gmx\.(de|net|co\.uk)$/ but then I discovered that gmx.co.uk had been added to the domain_awl table. I deleted the entry from PostgreSQL, but next time mx0.gmx.de [213.165.64.100] connected the following was logged by SQLgrey: new: 213.165.64: und...@gm... -> und...@sz... I'm sure it wasn't like that before v1.5.1. Anyone? --=20 Klaus Alexander Seistrup SubZeroNet =B7 Copenhagen =B7 Denmark |
From: Klaus A. S. <kse...@gm...> - 2005-03-11 13:06:22
|
I wrote: > # GMX > /^(mail|mx0|pop|imap)\.gmx\.(de|net|co\.uk)$/ Gmail's outgoing servers: # Gmail /^[mrw]proxy\.gmail\.com$/ are being ignored, too... --=20 Klaus Alexander Seistrup SubZeroNet =B7 Copenhagen =B7 Denmark |
From: Lionel B. <lio...@bo...> - 2005-03-11 13:23:43
|
Klaus Alexander Seistrup wrote the following on 11.03.2005 14:06 : >I wrote: > > > >># GMX >>/^(mail|mx0|pop|imap)\.gmx\.(de|net|co\.uk)$/ >> >> > >Gmail's outgoing servers: > ># Gmail >/^[mrw]proxy\.gmail\.com$/ > >are being ignored, too... > > > I'll look into it this evening or this week-end. |
From: Lionel B. <lio...@bo...> - 2005-03-14 21:47:18
|
Lionel Bouton wrote the following on 11.03.2005 14:23 : > Klaus Alexander Seistrup wrote the following on 11.03.2005 14:06 : > >> I wrote: >> >> >> >>> # GMX >>> /^(mail|mx0|pop|imap)\.gmx\.(de|net|co\.uk)$/ >>> >> >> >> Gmail's outgoing servers: >> >> # Gmail >> /^[mrw]proxy\.gmail\.com$/ >> >> are being ignored, too... >> >> >> > I'll look into it this evening or this week-end. > Just tested with 1.5.3. WORKSFORME(tm). When SQLgrey detects a change in the local file it logs a reload like this (even with 'quiet'): Mar 14 22:33:38 ns sqlgrey: reloading /etc/sqlgrey/clients_fqdn_whitelist.local just add a blank line somewhere and wait for an SMTP connexion... If it doesn't log a line like this, here's what could have happened: The code works by checking the mtime of the *.local files (if the file doesn't exists it is considered having a 0 mtime). I chose this method and not a content check because the check is done on *each* request to SQLgrey. A stat call is much much faster than a file open and read... The only reason why the reloading wouldn't work is if these *.local files traveled into the past. Either because at one time they were in the future or the last update put them in the past... Probable solution: restart SQLgrey and don't handle these files on systems in the future, past or an alternate dimension. Cheers, Lionel. |
From: Klaus A. S. <kse...@gm...> - 2005-03-14 22:30:04
|
On Mon, 14 Mar 2005 22:47:08 +0100, Lionel Bouton <lio...@bo...> wrote: >>> /^(mail|mx0|pop|imap)\.gmx\.(de|net|co\.uk)$/ >>> /^[mrw]proxy\.gmail\.com$/ >>> >>> are being ignored, too... >=20 > Just tested with 1.5.3. WORKSFORME(tm). >=20 > When SQLgrey detects a change in the local file it logs a reload like > this (even with 'quiet'): > Mar 14 22:33:38 ns sqlgrey: reloading > /etc/sqlgrey/clients_fqdn_whitelist.local > just add a blank line somewhere and wait for an SMTP connexion... >=20 > If it doesn't log a line like this, here's what could have happened: The files get reloaded, but SQLgrey doesn't take into account the clients_fqdn_whitelist.local file. The clients_fqdn_whitelist.local is being used, though. This is what it looked like a few minutes ago when I touched the two *.local files: <snip> reloading /etc/sqlgrey/clients_ip_whitelist.local reloading /etc/sqlgrey/clients_fqdn_whitelist.local domain_awl-match: updating gmx.co.uk, 213.165.64 from_awl-match: updating 64.233.184: x@y.z whitelist: a@b.c, 81.7.132.92(linuxnews.dk) d@e.f </snip> > Probable solution: restart SQLgrey and don't handle these files on > systems in the future, past or an alternate dimension. My mailbox is running NTP and file times look sane: <snip> $ stat *.local File: `clients_fqdn_whitelist.local' Size: 1616 Blocks: 8 IO Block: 4096 regular file Device: 2101h/8449d Inode: 897494 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2005-03-14 23:16:03.000882252 +0100 Modify: 2005-03-14 23:12:02.050540707 +0100 Change: 2005-03-14 23:12:02.050540707 +0100 File: `clients_ip_whitelist.local' Size: 683 Blocks: 8 IO Block: 4096 regular file Device: 2101h/8449d Inode: 897588 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2005-03-14 23:16:02.996882861 +0100 Modify: 2005-03-14 23:12:02.050540707 +0100 Change: 2005-03-14 23:12:02.050540707 +0100 $=20 </snip> Is there any way (perhaps a perl switch, or something) to check if the regexps used in the two files are all valid? Or is the only other solution to upgrade to v1.5.3? Cheers, --=20 Klaus Alexander Seistrup SubZeroNet =B7 Copenhagen =B7 Denmark |
From: Lionel B. <lio...@bo...> - 2005-03-14 22:51:36
|
Klaus Alexander Seistrup wrote the following on 14.03.2005 23:29 : >On Mon, 14 Mar 2005 22:47:08 +0100, Lionel Bouton ><lio...@bo...> wrote: > > Hum, seems this is a long standing bug with regexps in fqdn whitelists. I've reproduced it on my server. Currently tracking down the cause... Lionel. |
From: Klaus A. S. <kse...@gm...> - 2005-03-14 22:56:36
|
Lionel Bouton wrote: > I've reproduced it on my server. Currently tracking down the cause... Nice. :-) --=20 Klaus Alexander Seistrup SubZeroNet =B7 Copenhagen =B7 Denmark |
From: Lionel B. <lio...@bo...> - 2005-03-14 23:09:20
|
Klaus Alexander Seistrup wrote the following on 14.03.2005 23:56 : >Lionel Bouton wrote: > > > >>I've reproduced it on my server. Currently tracking down the cause... >> >> > >Nice. :-) > > > 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. Lionel |
From: Klaus A. S. <kse...@gm...> - 2005-03-15 00:05:50
|
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 |