looks like CAPITALS-Bug in library

Hi,

after a lot of digging we think we found a bug in the python spf library..

I use  postfix-policyd-spf-python  , now in version 1.3.1; Jun 4, 2014
on debian wheezy (paket from wheezy-backports)
(version 1.0.1 (wheezy) showed the same behaviour)


I noticed that one specific sender-domain got rejected because
of  "mailfrom not authenticated"  - but the test passes on the website
http://www.openspf.org/Why?s=3Dmfrom;id=3D...

strange.. It is hard to argument to the customer why his mails got rejected
when even the reference says everything looks ok ..

The manual check on the mailserver failed also:

python -m spf -v 192.168.0.10  [email protected] example.org


But - a check on a different server showed a "pass" - only difference
were the
used nameservers (resolvers)
=20
I then changed the nameservers in the resolv.conf and voila - the
check passes!

So the behaviour of the upstream DNS-servers was different - we found out
it has most probably something to do with this article from the isc:

https://deepthought.isc.org/article/AA-01113/0/Case-Insensitive-Response-Co=
mpression-May-Cause-Problems-With-Mixed-Case-Data-and-Non-Conforming-Client=
s.html

The DNS-server running bind 9.9.5 changed the capitalization of the
answer which made
the python library call fail.

Since bind 9.10 there is the option no-case-compress , which leads to
the same answer as the question
regarding the capitals and so the mail passes correctly.

Example:

Step one:

nslookup -q=3Dtxt example.org

Non-authoritative answer:
example.org  text =3D "v=3Dspf1 a mx:EXAMPLE.org ..."

So we found an spf-record.. now let's see what the mx-entry looks like:

dig EXAMPLE.org mx;; ANSWER SECTION:
example.org.                3       IN      MX      10 mail.example.org.


(answer from a bind 9.9.5 - Server)

and:

;; ANSWER SECTION:
EXAMPLE.de.                 60      IN      MX      10 mail.EXAMPLE.org.

(answer from a bind 9.10 - server.  See the Capitals?)

This appears also to be the difference for the a-record:

dig @<bind-9.9.5-nameserver> mail.EXAMPLE.org a

;; ANSWER SECTION:
mail.example.org.            60      IN      A       192.168.0.10

..or...

dig @<bind-9.10-nameserver> mail.EXAMPLE.org a

;; ANSWER SECTION:
mail.EXAMPLE.de.            60      IN      A       192.168.0.10



In the first variant policyd-spf will fail , the second one passes. This is
not only a bug in DNS (which has been fixed), but also a bug in the
behaviour of the policyd as dns-client; say in the spf-library. (see rfc
1034 for this)

Too bad that the option no-case-compress just does not exist
in bind 9.9.5 ..

best greetings,

Gunther