Recent changes to bugs

IPv6 mail from Google

Miha Verlic — Wed, 20 Feb 2013 18:18:20 -0000

Hello,

there is a problem with IPv6 mail coming from Google (sqlgrey 1.8.0). Apparently retries are made by several different servers, not even withint the same /64 subnet... any ideas how to handle this?

Feb 12 18:18:04 new: 2607:f8b0:4001:0c02:0000:0000:0000:0230(2607:f8b0:4001:c02::230), xxx@gmail.com -> mailbox
Feb 12 18:24:09 new: 2607:f8b0:4001:0c02:0000:0000:0000:022b(2607:f8b0:4001:c02::22b), xxx@gmail.com -> mailbox
Feb 12 18:47:28 new: 2607:f8b0:4001:0c02:0000:0000:0000:0229(2607:f8b0:4001:c02::229), xxx@gmail.com -> mailbox
Feb 12 19:11:48 new: 2607:f8b0:4001:0c03:0000:0000:0000:022e(2607:f8b0:4001:c03::22e), xxx@gmail.com -> mailbox
Feb 12 20:01:46 new: 2607:f8b0:4001:0c02:0000:0000:0000:022c(2607:f8b0:4001:c02::22c), xxx@gmail.com -> mailbox
Feb 12 21:03:28 new: 2607:f8b0:4001:0c03:0000:0000:0000:022b(2607:f8b0:4001:c03::22b), xxx@gmail.com -> mailbox
Feb 12 22:20:47 new: 2607:f8b0:4001:0c03:0000:0000:0000:0230(2607:f8b0:4001:c03::230), xxx@gmail.com -> mailbox
Feb 12 23:32:57 new: 2607:f8b0:4001:0c03:0000:0000:0000:0235(2607:f8b0:4001:c03::235), xxx@gmail.com -> mailbox
Feb 13 01:26:09 reconnect ok: 2607:f8b0:4001:0c02:0000:0000:0000:022b(2607:f8b0:4001:c02::22b), xxx@gmail.com -> mailbox (07:02:00)

Ability to modify the 450 smtp error message

Anonymous — Sat, 16 Jun 2012 19:49:41 -0000

Hi,

I am not sure whether this is a good idea or not (but some greylist implementations permit it, eg : gld) but would it be possible for sqlgrey to implement the possibility to modify the 450 smtp session error message sent when greylisting a triplet?
So that instead of "Recipient address rejected: Greylisted for X minutes", the message can be tweaked to anything, like, eg : "Server temporarily unavailable, please try again later".
My idea so far is to not display to any human that greylisting is implemented, since the sending SMTP server doesn't care about anything appart from the 4xx message, and since spammers could still implement a retry feature based on this default error message.

Thanks :)

hughes.net identified as dynamic

Anonymous — Tue, 29 Mar 2011 04:26:26 -0000

I don't think the regexp from hell that sorts out known end-user / dynamic pools patters works correctly for hughes.net satellite internet customers, as shown in this log entry. This is an ISP is using a large server farm that takes forever to get whitelisted, if ever...

sqlgrey: grey: identified dynamic pattern (last IP byte): smtprelay0148.b.hostedemail.com, 64.98.42.148: Using full IP.

Sqlgrey becomes unresponsive if MySQL server is unavailable

rcb — Mon, 05 Jul 2010 11:06:12 -0000

Version: 1.8.0rc2-1

Sqlgrey behaves normally when the mysql server is killed with e.g. /etc/init.d/mysql stop, postfix then continues to deliver e-mail normally
When the server becomes unavailable for other reasons, for example using 'iptables -A INPUT -p tcp --dport 3306 -j DROP', then two different things happen.
- Sqlgrey dies, resulting in 'warning: connect to 127.0.0.1:2501: Connection refused', which gives postfix configuration errors and 4.3.5 error messages to the clients.
- Sqlgrey keeps waiting for the connection to timeout, this results in messages like 'dbaccess: can't connect to DB: Can't connect to MySQL server on '127.0.0.1' (110)'. The effect is the same, 4.3.5 error messages to the clients.

This can be reproduced by firewalling MySQL using 'iptables -A INPUT -p tcp --dport 3306 -j DROP'

Memory usage

Frank Urban — Wed, 31 Mar 2010 05:40:08 -0000

Sometime ago I switched from Version 1.6 to 1.7, because I want to used the db_cluster function.
Since this time (I thing), I can see that the greylisting daemon is using more and more ram over the time. Greylisting is running on a heavy loaded machine with a lot of hardware power: 4x4 CPU and 32GByte Ram. After one month greylisting takes up to 16Gbyte from the 32GByte. Restarting is not possible. I need to kill -9 the daemon before I can start again.

That's how it look now on one server:
sqlgrey 4585 1 11 Mar17 ? 1-16:00:27 /usr/bin/perl -w /usr/sbin/sqlgrey -d

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4585 sqlgrey 20 0 8001m 7.8g 3184 S 4 24.7 2400:31 sqlgrey

sqlgrey DB insert race condition

Anonymous — Thu, 18 Feb 2010 11:55:58 -0000

Hi,

we just started using sqlgrey in a production environment. Its a great tool and has drasticly lowered our incoming spam!

Im noticing a race condition which is causing a couple of errors per day on our different mailservers, like:

Feb 18 12:14:29 mx2 sqlgrey: dbaccess: warning: couldn't do query: INSERT INTO from_awl (sender_name, sender_domain, src, first_seen, last_seen) VALUES('x','y','z','2010-02-18 11:59:28',NOW()): , reconnecting to DB

We currently have a setup with 3 mailservers in every zonefile, same prio. Mail is quite evenly spread over these servers. All the servers use a central sqlgrey database to keep track of the greylisting.

What happens is, sometimes a mail arrives at mx1 and mx2 at exactly the same time, from the same server and sender. Sqlgrey checks DB from both mailservers and decides the the sender can be added to from_awl. The mailserver which succeeds the first in the resulting INSERT wins. The looser gets an sql error because of the duplicate primary key and decides he needs to reconnect to MySQL and issue an error per e-mail.

There could be several workarounds for this, maybe disabling the primary key so a duplicatie entry doesn't result in error (dunno if duplicate entries will create other probs). Another option would be to use MySQL "INSERT.... ON DUPLICATE KEY UPDATE" type query.

Id like to know if you acknowledge this as a bug or if you have any suggestions.

Thanks!
Robin

problem with class_c() and IPv6 addressess

Piotr Meyer — Sat, 20 Jun 2009 13:50:01 -0000

class_c function has, inside join, call to $splitted[0 .. x] instead @splitted[0 .. x]. First form provides only second element of array (returns 1) instead range form first to x and has impact on connect table (only second block IPv6, ':'-separated block is placed inside).

This behaviour exists in both 1.6.x a 1.7.x branches. Trivial patch in attachement.

SqlGrey + MySQL 5.0.72 gives segfault

Anonymous — Fri, 05 Dec 2008 22:50:32 -0000

Hello!

I successfully installed the sqlgrey-1.7.6 under gentoo. After the table creation I gave a sefault from sqlgrey to mysql.so and the program quit. Could you help me?

from logs:
Nov 30 11:01:58 www /etc/init.d/sqlgrey[25221]: WARNING: sqlgrey has already been started
Nov 30 11:02:10 www sqlgrey: Process Backgrounded
Nov 30 11:02:10 www sqlgrey: 2008/11/30-11:02:10 sqlgrey (type Net::Server::Multiplex) starting! pid(25243)
Nov 30 11:02:10 www sqlgrey: Binding to TCP port 2501 on host 127.0.0.1
Nov 30 11:02:10 www sqlgrey: Setting gid to "410 410"
Nov 30 11:02:10 www sqlgrey: Setting uid to "102"
Nov 30 11:03:03 www postfix/smtpd[25317]: connect from ug-out-1314.google.com[66.249.92.169]
Nov 30 11:03:04 www sqlgrey[25243]: segfault at 8 ip 00007f13efbfe0ee sp 00007ffffaa38c70 error 4 in mysql.so[7f13efbaf000+13400
0]
Nov 30 11:03:04 www sqlgrey: 2008/11/30-11:03:04 CONNECT TCP Peer: "127.0.0.1:53453" Local: "127.0.0.1:2501"
Nov 30 11:03:04 www sqlgrey: optin: greylisting active for xy@yz.ab
Nov 30 11:03:05 www postfix/smtpd[25317]: warning: connect to 127.0.0.1:2501: Connection refused
Nov 30 11:03:05 www postfix/smtpd[25317]: warning: problem talking to server 127.0.0.1:2501: Connection refused
Nov 30 11:03:05 www postfix/smtpd[25317]: NOQUEUE: reject: RCPT from ug-out-1314.google.com[66.249.92.169]: 451 4.3.5 Server con
figuration problem; from=<df@ps.dd> to=<xy@yz.ab> proto=ESMTP helo=<ug-out-1314.google.com>
Nov 30 11:03:05 www postfix/smtpd[25317]: disconnect from ug-out-1314.google.com[66.249.92.169]

packages:
http://gentoo-portage.com/
versions:
dev-lang/perl-5.8.8-r5
dev-perl/DBI-1.607
dev-perl/IO-Multiplex-1.10
dev-db/mysql-5.0.72-r1

I running sqlgrey under 64 bit, and perl don't compiled with ithreads support.

Ipv6 addresses in client_whitelist are ignored

Patrick Vande Walle — Tue, 21 Oct 2008 09:41:02 -0000

IPv6 addresses in client_ip_whitelist and client_ip_whitelist.local are ignored.

The following patch is against 1.7.6 and does two things:

1. It changes the regexp to identify IPv6 addresses. Letters in addresses are case-insensitive per the IPv6 specs.
2. It correctly reads the IPv6 addresses in client_ip_whitelist and client_ip_whitelist.local

sqlgrey segfaults after Mysql Timeout

sah — Thu, 11 Sep 2008 08:11:48 -0000

I think it may be better do open a new issue report for this, even I'd posted this in the closed issue #1965695.

SQLgrey get's a segfault when not connected to for a longer time:

kernel: [687872.658710] sqlgrey[3190]: segfault at 4 ip b7b84874 sp bfdbae40 error 4 in libmysqlclient.so.15.0.0[b7b16000+1a4000]

After some investigation, I can say this:

The problem is caused by the mysqld connection timeout (wait_timeout parameter). Setting this parameter to somewhat like 600 seconds makes it easy to reproduce.

If I'm getting this right, sqlgrey starts a connection to mysqld, the first time sqlgrey is accessed by postfix. This connection is kept open by sqlgrey all the time.
If there's no other connect within 8 hours (the default for wait_timeout) or what ever wait_timeout is set to, sqlgrey will seqfault the next time it gets a connection and tries to use it's (timeouted) mysqlconnection.

So the problem is, sqlgrey does not detect this timeout right and is not able to reconnect to mysql.

I don't know if this problem can be resolved by sqlgrey, or if it's a problem in perl DBI, but I guess there should be a way to get this right, even if a timeout of 8 hours may not be reached in most enviroments.

Best regards