libspf2 IS broken

I found, after having used the libspf2/exi-scan patch awhile, that libspf2
is in fact broken. I posted about this on the spf-discussion list and have
only gotten one response from some one who remembers the issue being
discussed before. His solution was for me to contact an rather large
orgaisation and recommened the use ptr:domainnotation in their records to
get around the broken library that some people (read anyone using exiscan)
are using.

The problem revolves around the use of the ptr mechanism with in an included
spf record. Apparently the library uses the primary domain rather than the
included domain to test the ptr returns.... Ooops! that will, obviously, not
work.

The reason I am posting here is two fold:

	1. So people are aware that they will receive a *hard fail* on any host
that
		uses an include: with a ptr mech (just ptr), which is, of course valid and
		not all that uncommon for large orgs.

	2. To recommend either removing the libspf2 patch, and library from exiscan
            or at least be very up front and change it from experimental to
known
            to be broken and likely to lose real mail.

It's not the patch that is the problem, rather it's the actual spf2 library.

I ran across this when a media buyer was unable to get email from a TV
station, wrtv.com, which is a subsidiary of McGraw-Hill. I had noticed the
spf failures but considered them to be a real failure, especially since the
return was "fail", outright.

McGraw-Hill assured me the host in question was certainly covered in the
wrtv.com spf records so I looked at the records and the host in question
would absolutely qualify. I then went to the pobox.com/why.html link
generated by spfquery and that url returned "pass". But I noticed they used
spfqtool (part of libspf) so I built libspf and tried the same data with
both libspf2 (spfquery) and libspf (spfqtool) and the results are below.
This, in my opinion, is a very bad thing unless you enjoy cruising through
all of your spf rejects to make sure they are in fact "fail"ing.

First check the spf record for wrtv.com

host -t TXT wrtv.com
wrtv.com text "v=spf1 a:qbert.ibsys.com a:anubis.ibsys.com
a:treets100.ibsys.com include:mcgraw-hill.com -all"


it contains an include: for mcgraw-hill.com so now check the spf record
for mcgraw-hill

host -t TXT mcgraw-hill.com
mcgraw-hill.com text "v=spf1 ip4:66.54.164.0/24 ip4:64.94.160.128/26 mx
ptr -all"

now using spfquery from libspf2 the query fails

spfquery -i 198.45.18.176 -s [email protected] -h corp148mr3-11.mcgraw-hill.com
fail
Please see
http://spf.pobox.com/why.html?sender=xxx%40wrtv.com&ip=198.45.18.176&receive
r=spfquery
spfquery: domain of wrtv.com does not designate 198.45.18.176 as permitted
sender
Received-SPF: fail (spfquery: domain of wrtv.com does not designate
198.45.18.176 as permitted sender) client-ip=198.45.18.176;
[email protected]; helo=corp148mr3-11.mcgraw-hill.com;


but using libspf spfqtool it passes (as it should) and note the pass is on
the ptr, which
libspf2 will always fail.

spfqtool -i 198.45.18.176 -s [email protected] -h corp148mr3-11.mcgraw-hill.com
SPF short result:   pass
SPF verbose result: policy result: (pass) from rule (ptr)
RFC2822 header:     Received-SPF: pass (corp148mr3-11.mcgraw-hill.com:
domain of [email protected] designates 198.45.18.176 as permitted sender)
receiver=corp148mr3-11.mcgraw-hill.com; client_ip=198.45.18.176;
[email protected];

 Rick Cooper


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.