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=mfrom;id=...
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 someaddress@example.org example.org
But - a check on a different server showed a "pass" - only difference
were the
used nameservers (resolvers)
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-Compression-May-Cause-Problems-With-Mixed-Case-Data-and-Non-Conforming-Clients.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=txt example.org
Non-authoritative answer:
example.org text = "v=spf1 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
-------------------------------------------
Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
Archives: https://www.listbox.com/member/archive/1007/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1007/1311533-9e42a648
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311533&id_secret=1311533-d322f1f1
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311533&id_secret=1311533-d59c80a0&post_id=20160310105138:F78C3302-E6D7-11E5-AD88-C8E6EF10038B
Powered by Listbox: http://www.listbox.com
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=mfrom;id=...
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 someaddress@example.org example.org
But - a check on a different server showed a "pass" - only difference
were the
used nameservers (resolvers)
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-Compression-May-Cause-Problems-With-Mixed-Case-Data-and-Non-Conforming-Clients.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=txt example.org
Non-authoritative answer:
example.org text = "v=spf1 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
-------------------------------------------
Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
Archives: https://www.listbox.com/member/archive/1007/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1007/1311533-9e42a648
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311533&id_secret=1311533-d322f1f1
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311533&id_secret=1311533-d59c80a0&post_id=20160310105138:F78C3302-E6D7-11E5-AD88-C8E6EF10038B
Powered by Listbox: http://www.listbox.com