These errors would appear to be coming from the Mail::SPF::Query package,
when spamassassin's Plugin/SPF.pm eval's the Mail::SPF::Query's ->query() method.

Did you get the Mail::SPF::Query package from Fedora Extras? 

Which version of  Mail::SPF::Query are you using ?

Mail::SPF::Query would appear to depend on quite a few other packages, some of
which are not in Fedora Extras:

Net::CIDR::Lite: in Extras as perl-Net-CIDR-Lite-0.18-2.fc4
Sys::Hostname::Long ( not in Extras at all )

What versions of these packages are you using ? Did you install them from Extras
or from CPAN ?

(In reply to comment #1)
> Mail::SPF::Query would appear to depend on quite a few other packages, some of
> which are not in Fedora Extras:
> 
> Net::CIDR::Lite: in Extras as perl-Net-CIDR-Lite-0.18-2.fc4
> Sys::Hostname::Long ( not in Extras at all )

The Extras version of Mail::SPF::Query was patched not to need/use
Sys::Hostname::Long. Other than that, all of the necessary dependencies are
available from Core or Extras. Otherwise, the package would never have passed
review (and I was the reviewer).

I'm using perl-Mail-SPF-Query-1.997-4.fc4 from extras.

I've only installed the following packages from CPAN:

Net::XMPP
Net::Jabber
Log::Log4perl

This didn't include CPAN dependencies, but from inspecting my ~/.cpan/build, I
can see only those modules were built:

Archive-Tar-1.26
Bundle-libnet-1.00
Compress-Zlib-1.41
CPAN-1.80
Digest-MD5-2.36
Log-Log4perl-1.02
Net-Jabber-2.0
Net-Telnet-3.03
Net-XMPP-1.0
PathTools-3.14
TermReadKey-2.30
Term-ReadLine-Perl-1.0203
XML-Stream-1.22

Well, having a look at the Mail::SPF::Query package, I'm not sure it is working
correctly at all.

I downloaded the http://www.schlitt.net/spf/tests/ "SPF Test Suite", and 
EVERY test failed - not one test was successful - even after editing the
tests to fix the broken '-sanitize=1 and -debug=1' spfquery arguments.
Test log attached.

Hence, it appears Mail::SPF::Query is not up to the job - removing it :
  $ rpm -e perl-Mail-SPF-Query
will resolve this bug.

Created attachment 123875 [details]
log from SPF test suite 'tests_single' run

What happens when you run some of the commands from the SPF test suite log 
above - eg:

# spfquery -default-explanation=explanation -sanitize -debug -ip=192.0.2.11
  -sender=10.spf1-test.mailzone.com -helo=10.spf1-test.mailzone.com

Do you get a perl error ?

Seems OK (BTW, it didn't accept plain "-debug", it needs a numeric argument,
e.g. "-debug 1"):

[root@nmail tests_v2.1]# ./spfquery.pl.pre-1.997
-default-explanation=explanation -sanitize -debug 1 -ip=192.0.2.11
-sender=10.spf1-test.mailzone.com -helo=10.spf1-test.mailzone.com
|         10.spf1-test.mailzone.com new: ipv4=192.0.2.11,
sender=10.spf1-test.mailzone.com, helo=10.spf1-test.mailzone.com
|        postmaster 10.spf1-test.mailzone.com localpart is postmaster
|        postmaster 10.spf1-test.mailzone.com   DirectiveSet override: is
10.spf1-test.mailzone.com in the override hash?
|        postmaster 10.spf1-test.mailzone.com   DirectiveSet override: is
*.spf1-test.mailzone.com in the override hash?
|        postmaster 10.spf1-test.mailzone.com   DirectiveSet override: is
*.mailzone.com in the override hash?
|        postmaster 10.spf1-test.mailzone.com   DirectiveSet override: is *.com
in the override hash?
|        postmaster 10.spf1-test.mailzone.com   DirectiveSet override: is *. in
the override hash?
|        postmaster 10.spf1-test.mailzone.com   DirectiveSet->new(): doing TXT
query on 10.spf1-test.mailzone.com
|        postmaster 10.spf1-test.mailzone.com   myquery: doing TXT query on
10.spf1-test.mailzone.com
|        postmaster 10.spf1-test.mailzone.com   DirectiveSet->new(): TXT query
on 10.spf1-test.mailzone.com returned error=, last_dns_error=NOERROR
|        postmaster 10.spf1-test.mailzone.com   DirectiveSet->new(): SPF policy:
 mx                                          -all
|        postmaster 10.spf1-test.mailzone.com   lookup:   TXT  mx              
                           -all
|        postmaster 10.spf1-test.mailzone.com   lookup:   TXT prefix=+, lhs=mx, rhs=
|        postmaster 10.spf1-test.mailzone.com   lookup:   TXT prefix=-, lhs=all,
rhs=
|        postmaster 10.spf1-test.mailzone.com   lookup:  mec mechanisms=+mx() -all()
|        postmaster 10.spf1-test.mailzone.com   evaluate_mechanism: +mx() for
domain=10.spf1-test.mailzone.com
|        postmaster 10.spf1-test.mailzone.com   myquery: doing MX query on
10.spf1-test.mailzone.com
|        postmaster 10.spf1-test.mailzone.com   myquery: doing A query on
mx01.spf1-test.mailzone.com
|        postmaster 10.spf1-test.mailzone.com   mechanism mx: we have a match;
10.spf1-test.mailzone.com MX mx01.spf1-test.mailzone.com A 192.0.2.11 == 192.0.2.11
|        postmaster 10.spf1-test.mailzone.com   evaluate_mechanism: +mx()
returned hit 10.spf1-test.mailzone.com MX mx01.spf1-test.mailzone.com A 192.0.2.11
|        postmaster 10.spf1-test.mailzone.com   saving result pass to cache
point and returning.
|        postmaster 10.spf1-test.mailzone.com header_comment: spf_source =
domain of 10.spf1-test.mailzone.com
|        postmaster 10.spf1-test.mailzone.com header_comment: spf_source_type =
original-spf-record
pass
explanation: 10.spf1-test.mailzone.com MX mx01.spf1-test.mailzone.com A 192.0.2.11
spfquery: domain of 10.spf1-test.mailzone.com designates 192.0.2.11 as permitted
sender
Received-SPF: pass (spfquery: domain of 10.spf1-test.mailzone.com designates
192.0.2.11 as permitted sender) client-ip=192.0.2.11;
envelope-from=10.spf1-test.mailzone.com; helo=10.spf1-test.mailzone.com;

Created attachment 124461 [details]
spamassassin-3.0.4-2.fc4's /usr/lib/perl5/vendor_perl/5.8.6/Mail/SpamAssassin/Plugin/SPF.pm modified to log more debug info on SPF query failures

I think these SPF lookup failures are occuring when the DNS lookups timeout / 
fail, possibly due to intermittent loss of network connectivity.

Here's an SPF.pm that will log more info when these failures occur that should
give us a better idea of their cause. 

Please copy the attached SPF.pm to
/usr/lib/perl5/vendor_perl/5.8.6/Mail/SpamAssassin/Plugin/SPF.pm ,
restart spamd, and then grep for the log messages it might output:
  # egrep '(SPF: failed query:)|(SPF: DNS connectivity)' /var/log/messages
and append such messages to this bug report if found - thanks!

I've now been running spamassassin with the Mail::SPF plugin installed on my
inbox on an FC-4 system with all the latest updates installed, without a 
single occurrence of this problem.
I think this problem is simply due to intermittent DNS network service failures
occurring leading to a timeout and the alarm signal handler firing, failing the
DNS query. 
Hence, this is being closed as NOTABUG.