> Aug 6 08:24:47.384 [6584] dbg: dns: is Net::DNS::Resolver available? yes
> Aug 6 08:24:47.384 [6584] dbg: dns: Net::DNS version: 0.49
Took some effort to find a Net::DNS that old (March 2005, 8+ years),
it is no longer on CPAN.
> # Current time GMT: Tue Aug 6 08:52:22 2013
> [...]
> Aug 6 08:52:41.425 [24111] warn: spf: lookup failed:
> Can't locate object method "new" via package "Net::DNS::RR::TXT"
That's 19.4 seconds between the two timestamps.
The DNS lookup timeout in Mail::SPF::Query is 15 seconds.
The [Can't locate object method "new" via package] happens
if the module in question was not loaded (require/use).
The Net::DNS::RR loads subordinate modules on-demand
when they are needed for the first time:
sub _get_subclass {
my ($class, $type) = @_;
return unless $type and $RR{$type};
my $subclass = join('::', $class, $type);
unless ($_LOADED{$subclass}) {
eval "require $subclass";
die $@ if $@;
$_LOADED{$subclass}++;
}
return $subclass;
}
If a timeout would occur in the middle of eval "require $subclass"
(where $subclass is "Net::DNS::RR::TXT"), the eval would exit
but the $@ would be empty, so the module Net::DNS::RR::TXT
may appear to be loaded but is not.
So my guess is that resolving for a TXT record on dnsbltest.spamassassin.org
took longer than 15 seconds, and it so happened that the module
Net::DNS::RR::TXT was not yet needed / not loaded as a result of
some previous query.
A "eval...; die $@ if $@" is a commonly used idiom, but is bad;
the proper idiom is: "eval ... or die", i.e. testing for the result
of eval, not depending on the value of $@.
Mark