Re: looks like CAPITALS-Bug in library

can i suggest providing the real domain names involved so anyone can replic=
ate/verify or possibly find alternate causation
im sure some can easily test against a range of versions of bind in differe=
nt modes

At 15:51 10/03/2016  Thursday, Gunther Nitzsche wrote:
> Hi,
>=20
> after a lot of digging we think we found a bug in the python spf library..
>=20
> 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)
>=20
> 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...
>=20
> strange.. It is hard to argument to the customer why his mails got reject=
ed
> when even the reference says everything looks ok ..
>=20
> The manual check on the mailserver failed also:
>=20
> python -m spf -v 192.168.0.10  [email protected] example.org
>=20
> 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!
>=20
> 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:
>=20
> https://deepthought.isc.org/article/AA-01113/0/Case-Insensitive-Response-=
Compression-May-Cause-Problems-With-Mixed-Case-Data-and-Non-Conforming-Clie=
nts.html
>=20
> The DNS-server running bind 9.9.5 changed the capitalization of the
> answer which made
> the python library call fail.
>=20
> 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.
>=20
> Example:
>=20
> Step one:
>=20
> nslookup -q=3Dtxt example.org
>=20
> Non-authoritative answer:
> example.org  text =3D "v=3Dspf1 a mx:EXAMPLE.org ..."
>=20
> So we found an spf-record.. now let's see what the mx-entry looks like:
>=20
> dig EXAMPLE.org mx;; ANSWER SECTION:
> example.org.                3       IN      MX      10 mail.example.org.
>=20
> (answer from a bind 9.9.5 - Server)
>=20
> and:
>=20
> ;; ANSWER SECTION:
> EXAMPLE.de.                 60      IN      MX      10 mail.EXAMPLE.org.
>=20
> (answer from a bind 9.10 - server.  See the Capitals?)
>=20
> This appears also to be the difference for the a-record:
>=20
> dig @<bind-9.9.5-nameserver> mail.EXAMPLE.org a
>=20
> ;; ANSWER SECTION:
> mail.example.org.            60      IN      A       192.168.0.10
>=20
> ..or...
>=20
> dig @<bind-9.10-nameserver> mail.EXAMPLE.org a
>=20
> ;; ANSWER SECTION:
> mail.EXAMPLE.de.            60      IN      A       192.168.0.10
>=20
> 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)
>=20
> Too bad that the option no-case-compress just does not exist
> in bind 9.9.5 ..
>=20
> best greetings,
>=20
> Gunther
>=20