From: Kyle L. <la...@uc...> - 2010-02-02 01:24:39
|
I'm testing the behavior of sqlgrey when the database is offline. The first problem is rare, and not likely to be triggered. If you start the database backend, start sqlgrey, and then kill the backend without any messages having hit sqlgrey, the daemon will die a nasty death in sub update_dbnow. There is a reference to $DBI::errstr (line 382) that, in these circumstances, is an uninitialized reference. The resulting error looks like: Use of uninitialized value in concatenation (.) or string at ./sqlgrey line 382. setconfig error One might perhaps consider this a bug in DBI, but it should be easy enough to work around. The second problem is a bit more subtle. In sub smtpd_access_policy, when the database is first accessed by a call to sub is_in_domain_awl, the return value is 1-- meaning the check succeeded. In reality, the check did not occur, because the database was offline; yet, what winds up in the headers is 'domain auto-whitelisted by...', which is misleading. This is clearly by design, and the desired behavior is occurring-- the message is accepted for delivery by postfix. It would be much more informative if there was first a check to see if the database was online, and if it was not available, to instead prepend a header saying something like 'database offline, message not greylisted'. I'm not perl-savvy, so I'm not immediately sure how best to go about this last one. If it was Python, I'd be raising an exception... --Kyle |