Two DNSBL bugs? --- Exim-specific

[Julian Field]

At 22:24 21/08/2003, you wrote:
> > 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).

Quite right. I put an extra ) after the {6} by mistake.

>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.

Seeing as we don't even know what output Exim will produce in this
situation, this is a bit of a theoretical point. Maybe Tony Finch might
know the answer to this one.
Tony --- Any thoughts?
--
Julian Field
www.MailScanner.info
Professional Support Services at www.MailScanner.biz
MailScanner thanks transtec Computers for their support