ok, that becomes LAUGHABLE - what sense does it make blow out dns-requests with ".sbl.spamhaus.org"

Aug  7 19:32:08 mail-gw spamd[16151]: Use of uninitialized value $4 in concatenation (.) or string at /usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/URIDNSBL.pm line 1042.
Aug  7 19:32:08 mail-gw spamd[16151]: Use of uninitialized value $3 in concatenation (.) or string at /usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/URIDNSBL.pm line 1042.
Aug  7 19:32:08 mail-gw spamd[16151]: Use of uninitialized value $2 in concatenation (.) or string at /usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/URIDNSBL.pm line 1042.
Aug  7 19:32:08 mail-gw spamd[16151]: dns: new_dns_packet (domain=...(.sbl.spamhaus.org. type=A class=IN) failed: a domain name contains a null label
Aug  7 19:32:08 mail-gw spamd[16151]: dns: new_dns_packet (domain=...(.zen.spamhaus.org. type=A class=IN) failed: a domain name contains a null label
Aug  7 19:32:08 mail-gw spamd[16151]: Use of uninitialized value $4 in concatenation (.) or string at /usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/URIDNSBL.pm line 1042.
Aug  7 19:32:08 mail-gw spamd[16151]: Use of uninitialized value $3 in concatenation (.) or string at /usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/URIDNSBL.pm line 1042.
Aug  7 19:32:08 mail-gw spamd[16151]: Use of uninitialized value $2 in concatenation (.) or string at /usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/URIDNSBL.pm line 1042.

I ran into this as well and it appears that it is due to behavior in Net::DNS::RR that is rather poorly documented. If the 'string' method is called, the result is a RFC1035-format RR which may be line-wrapped with the continuation lines encapsulated by (). See the common multi-line representation of SOA records for an example. As a result, with a long-enough hostname, the string that URIDNSBL tries to parse for an IP address actually is a multi-line string, the first line ending with '(' and no IP address. 

In short: this hits only long hostnames, with my preliminary testing getting 47 total characters being the maximum length that does not break, but that may be slightly variable between systems. 

Picking a fix is complicated by the recent flux in Net::DNS. The latest version includes a 'plain' method that "Returns a simplified single line representation of the RR" and so is more easily parsed for the IP octets. It also has a 'token' method that returns an array of tokens from the RR. Either should be usable and more reliable than using the 'string' method, but I need to research whether these are available in all of the Net::DNS versions SA supports

The uninitialized warning is suppressed by this change, but this reflects a problem in the caller.

sub lookup_dnsbl_for_ip {
  my ($self, $pms, $obj, $ip) = @_;
#ORIG
#  local($1,$2,$3,$4);
#  $ip =~ /^(\d+)\.(\d+)\.(\d+)\.(\d+)$/;
#  my $revip = "$4.$3.$2.$1";
#ENDORIG

#SSF
  my $revip;
  if ( $ip =~ /^(\d+)\.(\d+)\.(\d+)\.(\d+)$/ ) {
     $revip = "$4.$3.$2.$1";
  } else {
     #warn "Bad ip $ip";  This seems to be '(' all the time, maybe that's a clue?
     return;
  }
#ENDSSF

Hope that helps.
SSF

Bug #7231 includes both a minimal patch for this which has been applied to the 3.4 branch (r1694126) and 2 more extensive patches that have been applied to trunk (r1671621 and r1671622) 

Maintainers of OS packages would be well advised to integrate r1694126 pending the eventual 3.4.2 release.

*** This bug has been marked as a duplicate of bug 7231 ***

Incidentally, my idea of rewriting the code to use 'plain' or 'token' methods is inferior to Mark's patches for Bug #7231, as it would require Net::DNS v0.73 or later and would have left in place the suboptimal practice of parsing a text representation of a RR for an IP. The committed patches check the RR type and the trunk patch uses the 'address' method if it is available (since v0.69.)

(In reply to Bill Cole from comment #5)
> Incidentally, my idea of rewriting the code to use 'plain' or 'token'
> methods is inferior to Mark's patches for Bug #7231, as it would require
> Net::DNS v0.73 or later and would have left in place the suboptimal practice
> of parsing a text representation of a RR for an IP. The committed patches
> check the RR type and the trunk patch uses the 'address' method if it is
> available (since v0.69.)

Looking the Changes for Net::DNS:

**** 0.73 Nov 29, 2013

I don't really thing requiring >=0.73 is that much of a hardship...