Reject messages with valid SPF

[Maciej Mazurek]

Hello i have some rejection of emails from few domains

Example

Dec 30 11:59:30 mg1 postfix/smtpd[2628]: NOQUEUE: reject: RCPT from mailout.tpsa.pl[212.160.172.10]: 550 5.7.1 <email address hidden>: Recipient address rejected: Message rejected due to: SPF Permanent Error: No valid SPF record for included domain: spfc.orange.com: include:spfc.orange.com. Please see http://www.openspf.net/Why?s=mfrom;<email address hidden>;ip=212.160.172.10;<email address hidden>; from=<email address hidden> to=<email address hidden> proto=ESMTP helo=<mailin.tpsa.pl>

but when we go to
http://www.openspf.net/Why?s=mfrom;<email address hidden>;ip=212.160.172.10;<email address hidden>; from=<email address hidden> to=<email address hidden> proto=ESMTP helo=<mailin.tpsa.pl>

we have the mesage:
The domain orange.com has authorized mailout.tpsa.pl (212.160.172.10) to send mail on its behalf, so the message should have been accepted. It is impossible for us to say why it was rejected.

and spf's looks ok for this domain :

v=spf1 include:spfa.orange.com include:spfb.orange.com include:spfc.orange.com include:spfd.orange.com ~all

include:spfc.orange.com looks like this and iclude the ip (212.160.172.10)

v=spf1 ip4:176.31.76.233 ip4:176.31.226.197 ip4:176.31.231.211 ip4:178.237.109.60/31 ip4:178.237.110.10 ip4:185.14.244.10 ip4:185.14.245.10 ip4:185.14.246.10 ip4:185.14.247.10 ip4:193.251.160.202 ip4:193.251.160.226 ip4:193.251.215.88/29 ip4:194.2.79.61 ip4:194.7.23.25 ip4:194.51.78.40 ip4:194.51.78.44 ip4:195.25.6.26 ip4:195.25.111.233 ip4:196.203.232.30 ip4:196.203.232.158 ip4:199.91.137.26 ip4:212.34.2.241 ip4:212.34.2.243
ip4:212.160.172.10
ip4:194.2.204.212 ~all

so I think this is not a problem of the spf's in dns itself but the problem that this python policy does not run though all of "include:" ip's inside - maybe only first 10 like for the DNS lookups ?

[Maciej Mazurek (melmack)]

pypolicyd-spf-2.0.1
Python-3.6.0
pyspf-2.0.12
centos 6

[Scott Kitterman (kitterman)]

This is almost certainly a firewall problem somewhere. If you look at the size if the record (note the MSG SIZE at the end):

$ dig txt spfc.orange.com

; <<>> DiG 9.9.5-3ubuntu0.10-Ubuntu <<>> txt spfc.orange.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46460
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;spfc.orange.com. IN TXT

;; ANSWER SECTION:
spfc.orange.com. 86399 IN TXT "v=spf1 ip4:176.31.76.233 ip4:176.31.226.197 ip4:176.31.231.211 ip4:178.237.109.60/31 ip4:178.237.110.10 ip4:185.14.244.10 ip4:185.14.245.10 ip4:185.14.246.10 ip4:185.14.247.10 ip4:193.251.160.202 ip4:193.251.160.226 ip4:193.251.215.88/29" " ip4:194.2.79.61 ip4:194.7.23.25 ip4:194.51.78.40 ip4:194.51.78.44 ip4:195.25.6.26 ip4:195.25.111.233 ip4:196.203.232.30 ip4:196.203.232.158 ip4:199.91.137.26 ip4:212.34.2.241 ip4:212.34.2.243 ip4:212.160.172.10 ip4:194.2.204.212 ~all"

;; Query time: 48 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Fri Dec 30 08:16:50 EST 2016
;; MSG SIZE rcvd: 529

this is unlikely to fit in a UDP packet. If fact, when I tried spfc.orange.com in the validator at http://kitterman.com/spf/validate.html - which unlike others, checks for such potential problems, it did have to fall back to TCP. If you look at RFC 7208, section 3.4 - https://tools.ietf.org/html/rfc7208#section-3.4 - it advises to keep individual records smaller than this.

The most likely scenario is a fallback to TCP and DNS over TCP (port 53) being blocked so the DNS resolver never hears back and treats it as no answer.

I would suggest raising a ticket with orange.com, since their record is not compatible with a SHOULD requirement in RFC 7208 (SHOULD in IETF RFC terms has a stronger meaning than in natural language - they really need to fix this). You could also examine your network and try to figure out where the TCP reply got lost.

There's nothing either in the policy server or in the underlying pyspf library that has limits like this.

[Maciej Mazurek (melmack)]

Thanks I'll will try to contact Orange
But this is a rather big company so there might take some time

Nevertheless I've run the dig from my mailserver
And as you see there's full reply
Should I also try in some way by pyspf ?

[mmazurek@mg1 ~]$ dig txt spfc.orange.com
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6 <<>> txt spfc.orange.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55615
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 7

;; QUESTION SECTION:
;spfc.orange.com. IN TXT

;; ANSWER SECTION:
spfc.orange.com. 85151 IN TXT "v=spf1 ip4:176.31.76.233 ip4:176.31.226.197 ip4:176.31.231.211 ip4:178.237.109.60/31 ip4:178.237.110.10 ip4:185.14.244.10 ip4:185.14.245.10 ip4:185.14.246.10 ip4:185.14.247.10 ip4:193.251.160.202 ip4:193.251.160.226 ip4:193.251.215.88/29" " ip4:194.2.79.61 ip4:194.7.23.25 ip4:194.51.78.40 ip4:194.51.78.44 ip4:195.25.6.26 ip4:195.25.111.233 ip4:196.203.232.30 ip4:196.203.232.158 ip4:199.91.137.26 ip4:212.34.2.241 ip4:212.34.2.243 ip4:212.160.172.10 ip4:194.2.204.212 ~all"

;; AUTHORITY SECTION:
orange.com. 85149 IN NS h4.nstld.com.
orange.com. 85149 IN NS j4.nstld.com.
orange.com. 85149 IN NS k4.nstld.com.
orange.com. 85149 IN NS l4.nstld.com.
orange.com. 85149 IN NS a4.nstld.com.
orange.com. 85149 IN NS f4.nstld.com.
orange.com. 85149 IN NS g4.nstld.com.

;; ADDITIONAL SECTION:
a4.nstld.com. 8227 IN A 209.112.113.33
f4.nstld.com. 8227 IN A 69.36.145.33
g4.nstld.com. 8227 IN A 209.112.114.33
h4.nstld.com. 63535 IN A 69.36.145.33
j4.nstld.com. 63535 IN A 69.36.145.33
k4.nstld.com. 8227 IN A 69.36.145.33
l4.nstld.com. 8227 IN A 209.112.114.33

;; Query time: 0 msec
;; SERVER: 194.126.232.130#53(194.126.232.130)
;; WHEN: Fri Dec 30 14:53:37 2016
;; MSG SIZE rcvd: 755

[Scott Kitterman (kitterman)]

The path to the SPF module will be different on Centos (site-package versus dist-packages at the very least) since I'm on Debian. Here's an example of using pyspf to retrieve the record:

$ /usr/lib/python3/dist-packages/spf.py spfc.orange.com
v=spf1 ip4:176.31.76.233 ip4:176.31.226.197 ip4:176.31.231.211 ip4:178.237.109.60/31 ip4:178.237.110.10 ip4:185.14.244.10 ip4:185.14.245.10 ip4:185.14.246.10 ip4:185.14.247.10 ip4:193.251.160.202 ip4:193.251.160.226 ip4:193.251.215.88/29 ip4:194.2.79.61 ip4:194.7.23.25 ip4:194.51.78.40 ip4:194.51.78.44 ip4:195.25.6.26 ip4:195.25.111.233 ip4:196.203.232.30 ip4:196.203.232.158 ip4:199.91.137.26 ip4:212.34.2.241 ip4:212.34.2.243 ip4:212.160.172.10 ip4:194.2.204.212 ~all

You'll see it retrieves the whole record here.

[Maciej Mazurek (melmack)]

Thanks, close the ticket