http://bugzilla.spamassassin.org/show_bug.cgi?id=3794
------- Additional Comments From [EMAIL PROTECTED] 2004-09-20 16:38 -------
As I was saying in IRC: IMO, we need to use eval { } with Net::DNS.
1. Net::DNS contains several explicit calls to die()
/usr/lib/perl5/Net/DNS/Nameserver.pm: $sock->send($reply_data) or die "send:
$!";
/usr/lib/perl5/Net/DNS/Nameserver.pm: ) || die "couldn't create nameserver
object\n";
/usr/lib/perl5/Net/DNS/Packet.pm: # die "dn_expand: loop:
offset=$offset (seen = ",
/usr/lib/perl5/Net/DNS/RR.pm: die $@;
/usr/lib/perl5/Net/DNS/RR.pm: die "$rdata is inconsistent; length does
not match content"
/usr/lib/perl5/Net/DNS/RR.pm: die 'Expected RFC3597 representation of
RDATA'
/usr/lib/perl5/Net/DNS/RR.pm: die "$rdata is inconsistent; length does
not match content"
etc.
2. we don't currently have an eval{ } trap in the harvest_dnsbl_results() call
path from user code, so any die()s are propagated into the user code
3. Net::DNS' design is such that new objects are created, returned to us, and we
then are expected to call methods on those to get results. This means that
(similar to this bug) there are many situations where we might try to call a
method that doesn't exist by that name on the object we've been given; this
results in a die() from perl itself. The doco doesn't mention this case, but
then, according to the N:D documentation, this current bug should not exist
either, but yet it does. ;)
As far as I can see by a cursory examination, the Net::DNS object model
shouldn't screw up too much aside from this case, but I don't know for sure --
and that's subject to change in future N:D releases. for defensive-programming's
sake, we have to expect that we can receive die() exceptions from Net::DNS in
future.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
