Two DNSBL bugs?

[Malcolm Ray]

> Try this:
>
> --- Exim.pm.old    2003-05-30 09:38:27.000000000 +0100
> +++ Exim.pm     2003-08-21 21:02:46.000000000 +0100
> @@ -311,6 +311,8 @@
>                      defined $metadata{dv_host_address})?
>                        $metadata{dv_host_address}:
>                        "127.0.0.1";
> +  $message->{clientip} =~ s/^(\d+\.\d+\.\d+\.\d+)(\..*)?/$1/;
> +  $message->{clientip} =~ s/^([a-f\d]*)(:[a-f\d]*){6}).*$/$1$2/;
>
>     # Deal with b-tree of non-recipients
>     $metadata{nonrcpts} = {};

That won't even compile (you have mismatched parentheses).

Hmm... one thing that bothers me about this is that I don't see any guarantee
that inet_ntop (which is what's responsible for giving us the address string
in question) will always produce a string in a particular format.  RFC 3493
says: "The inet_ntop() function shall convert a numeric address into a
text string suitable for presentation".  Regardless of what particular
current implementations might do, it seems to me a compliant implementation
could return, say, '::ffff:192.168.1.2' or '::1'.  One option might be to
use Net::IPv6Addr::is_ipv6, but I haven't tested or benchmarked this.