python-policyd-spf failing on AOL SPF records.

[John Neffenger]

It seems that the long SPF records for "aol.com" are causing
python-policyd-spf to fail when getting the DNS TXT record by UDP.

Here are the TXT records fetched on www.volano.com:

$ host -t txt aol.com
;; Warning: Message parser reports malformed message packet.
;; Truncated, retrying in TCP mode.
aol.com descriptive text "v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24
ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24
ip4:64.12.136.0/23 ip4:64.12.138.0/24 ip4:64.12.143.99/32
ip4:64.12.143.100/32 ip4:64.12.143.101/32 ptr:mx.aol.com ?all"
aol.com descriptive text "spf2.0/pra ip4:152.163.225.0/24
ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23
ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24
ip4:64.12.143.99/32 ip4:64.12.143.100/32 ip4:64.12.143.101/32
ptr:mx.aol.com ?all"

Here is the timeout getting the TXT records on www.commspeak.com,
presumably because they're dropped by intervening routers:

$ host -t txt aol.com
;; connection timed out; no servers could be reached

The Postfix configuration on both machines is:

main.cf
-------
smtpd_recipient_restrictions =
    ...
    warn_if_reject check_policy_service unix:private/policy-spf
    ...

master.cf
---------
...
# Python Sender Policy Framework (SPF) Service
policy-spf unix - n n - - spawn
  user=nobody argv=/usr/bin/policyd-spf

In the Postfix log files, I get the following on www.volano.com:

Mar 14 11:24:39 ldc1042 postfix/smtpd[8296]: connect from
    imr-m06.mx.aol.com[64.12.138.200]
Mar 14 11:24:39 ldc1042 policyd-spf[8298]: :HELO client-ip=64.12.138.200;
    helo=imr-m06.mx.aol.com; <email address hidden>;
    <email address hidden>;
Mar 14 11:24:39 ldc1042 policyd-spf[8298]: SPF Temporary Error:
    DNS Ran off end of data:Mail From client-ip=64.12.138.200;
    helo=imr-m06.mx.aol.com; <email address hidden>;
    <email address hidden>;
Mar 14 11:24:39 ldc1042 postfix/smtpd[8296]: NOQUEUE: reject: RCPT
    from imr-m06.mx.aol.com[64.12.138.200]: 450 4.7.1 <email address hidden>:
    Recipient address rejected: Received-SPF: Temperror (SPF Temporary
    Error: DNS Ran off end of data) Mail From client-ip=64.12.138.200;
    helo=imr-m06.mx.aol.com; <email address hidden>;
    <email address hidden>; ; from=<email address hidden> to=<email address hidden>
    proto=ESMTP helo=<imr-m06.mx.aol.com>
Mar 14 11:24:40 ldc1042 postfix/smtpd[8296]: disconnect from
    imr-m06.mx.aol.com[64.12.138.200]

On www.commspeak.com I get:

Mar 14 09:24:07 www postfix/smtpd[2882]: connect from
    imr-m06.mx.aol.com[64.12.138.200]
Mar 14 09:24:08 www policyd-spf[2886]: :HELO client-ip=64.12.138.200;
    helo=imr-m06.mx.aol.com; <email address hidden>;
    <email address hidden>;
Mar 14 09:24:38 www policyd-spf[2886]: SPF Temporary Error: DNS
    Timeout:Mail From client-ip=64.12.138.200; helo=imr-m06.mx.aol.com;
    <email address hidden>; <email address hidden>;
Mar 14 09:24:38 www postfix/smtpd[2882]: NOQUEUE: reject: RCPT from
    imr-m06.mx.aol.com[64.12.138.200]: 450 4.7.1 <email address hidden>:
    Recipient address rejected: Received-SPF: Temperror (SPF Temporary Error:
    DNS Timeout) Mail From client-ip=64.12.138.200; helo=imr-m06.mx.aol.com;
    <email address hidden>; <email address hidden>;
    ; from=<email address hidden> to=<email address hidden> proto=ESMTP
    helo=<imr-m06.mx.aol.com>
Mar 14 09:24:40 www postfix/smtpd[2882]: disconnect from
    imr-m06.mx.aol.com[64.12.138.200]

ProblemType: Bug
Architecture: i386
Date: Sat Mar 22 12:46:20 2008
DistroRelease: Ubuntu 7.10
Package: python-spf 2.0.4-1
PackageArchitecture: all
SourcePackage: pyspf
Uname: Linux www 2.6.22-14-server #1 SMP Sun Oct 14 23:34:23 GMT 2007 i686 GNU/Linux

[Scott Kitterman (kitterman)]

Please provide log information from /var/log/mail.log showing the problem
you are having. Postfix and the policy server should provide suffficent
information to debug this.

[John Neffenger (jgneff)]

I edited the original Bug Description to provide additional information. (I reported the bug through "apport-cli" but didn't want to use elinks to enter all the info.) Oh, one more change -- the log files shown above are when I did not have "warn_if_reject" for the SPF checks. The log files correspond to:

main.cf
-------
smtpd_recipient_restrictions =
    ...
    check_policy_service unix:private/policy-spf
    ...

Thanks,
John Neffenger

[Scott Kitterman (kitterman)]

That's enough information. I'll have a look at it. I suspect this is
either a pthyon-dns limitation or a router firewall issue. DNS via TCP is
generally risky and not recommended.

[Scott Kitterman (kitterman)]

This isn't a problem in pyspf, but a firewall problem between you and aol. My internal router blocks DNS TCP queries. From behind that router I get the same type of result you do. From a server outside of the router, it works fine. There's nothing pyspf can do except fall back to TCP when the packet is to big for UDP.

[John Neffenger (jgneff)]

Thanks for looking into it. You must be getting the same result as one of my machines, but not the other. The other of the two machines shown above (www.volano.com) gets DNS TCP queries just fine, as shown here (with the "-T" flag):

john@ldc1042:~$ host -T -t txt aol.com
aol.com descriptive text "v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ip4:64.12.143.99/32 ip4:64.12.143.100/32 ip4:64.12.143.101/32 ptr:mx.aol.com ?all"
aol.com descriptive text "spf2.0/pra ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ip4:64.12.143.99/32 ip4:64.12.143.100/32 ip4:64.12.143.101/32 ptr:mx.aol.com ?all"

There's no router blocking DNS TCP requests on that machine, yet python-policyd-spf still fails on the machine getting the TXT records shown above with this message:

Mar 14 11:24:39 ldc1042 policyd-spf[8298]: SPF Temporary Error:
    DNS Ran off end of data:Mail From client-ip=64.12.138.200;
    helo=imr-m06.mx.aol.com; <email address hidden>;
    <email address hidden>;

It's as if it's not trying TCP at all -- just failing on the UDP request. I apologize for confusing the issue with the "DNS Timeout" message on the second machine behind the router (www.commspeak.com). Are you using python-policyd-spf and getting AOL messages without problems? For now, all messages from all AOL addresses are rejected (temporarily, over and over again) if I enable python-policyd-spf.

Thank you,
John

[John Neffenger (jgneff)]

Actually, I think the following series of commands are more helpful.

First the normal UDP request (with a fall-back to TCP):

john@ldc1042:~$ host -t txt aol.com
;; Warning: Message parser reports malformed message packet.
;; Truncated, retrying in TCP mode.
aol.com descriptive text "spf2.0/pra ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ip4:64.12.143.99/32 ip4:64.12.143.100/32 ip4:64.12.143.101/32 ptr:mx.aol.com ?all"
aol.com descriptive text "v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ip4:64.12.143.99/32 ip4:64.12.143.100/32 ip4:64.12.143.101/32 ptr:mx.aol.com ?all"

Then a direct TCP-only request, which works fine:

john@ldc1042:~$ host -T -t txt aol.com
aol.com descriptive text "spf2.0/pra ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ip4:64.12.143.99/32 ip4:64.12.143.100/32 ip4:64.12.143.101/32 ptr:mx.aol.com ?all"
aol.com descriptive text "v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ip4:64.12.143.99/32 ip4:64.12.143.100/32 ip4:64.12.143.101/32 ptr:mx.aol.com ?all"

Then on the same machine, asking spf.py to test an AOL address (using the client IP address and HELO name from the Postfix log files):

john@ldc1042:~$ python /usr/share/python-support/python-spf/spf.py 64.12.138.200 <email address hidden> imr-m06.mx.aol.com
('temperror', 451, 'SPF Temporary Error: DNS Ran off end of data')

That's the same error I'm getting in the mail log. Then on the same machine, asking spf.py just to get the AOL SPF records:

john@ldc1042:~$ python /usr/share/python-support/python-spf/spf.py aol.com
Traceback (most recent call last):
  File "/usr/share/python-support/python-spf/spf.py", line 1621, in <module>
    print q.dns_spf(sys.argv[1])
  File "/usr/share/python-support/python-spf/spf.py", line 1010, in dns_spf
    a = [t for t in self.dns_txt(domain) if RE_SPF.match(t)]
  File "/usr/share/python-support/python-spf/spf.py", line 1045, in dns_txt
    return [''.join(a) for a in self.dns(domainname, 'TXT')]
  File "/usr/share/python-support/python-spf/spf.py", line 1150, in dns
    for k, v in DNSLookup(name, qtype, self.strict):
  File "/usr/share/python-support/python-spf/spf.py", line 105, in DNSLookup
    raise TempError, 'DNS ' + str(x)
__main__.TempError: DNS Ran off end of data

I get the same thing running policyd-spf directly:

john@ldc1042:~$ policyd-spf
client_address=64.12.138.200
helo_name=imr-m06.mx.aol.com
<email address hidden>
<email address hidden>

action=defer_if_permit Received-SPF: Temperror (SPF Temporary Error: DNS Ran off end of data) Mail From client-ip=64.12.138.200; helo=imr-m06.mx.aol.com; <email address hidden>; <email address hidden>;

Do you get the same results?

Thanks,
John

[Scott Kitterman (kitterman)]

On Sunday 23 March 2008 02:22:51 John Neffenger wrote:

> john@ldc1042:~$ python /usr/share/python-support/python-spf/spf.py aol.com
> Traceback (most recent call last):
> File "/usr/share/python-support/python-spf/spf.py", line 1621, in
> <module> print q.dns_spf(sys.argv[1])
> File "/usr/share/python-support/python-spf/spf.py", line 1010, in dns_spf
> a = [t for t in self.dns_txt(domain) if RE_SPF.match(t)]
> File "/usr/share/python-support/python-spf/spf.py", line 1045, in dns_txt
> return [''.join(a) for a in self.dns(domainname, 'TXT')]
> File "/usr/share/python-support/python-spf/spf.py", line 1150, in dns
> for k, v in DNSLookup(name, qtype, self.strict):
> File "/usr/share/python-support/python-spf/spf.py", line 105, in
> DNSLookup raise TempError, 'DNS ' + str(x)
> __main__.TempError: DNS Ran off end of data

No. I don't get the same response, but that's definitely a valid python-dns
bug. Whatever the cause, python-dns shouldn't crash. I can have a look at
that.

[Scott Kitterman (kitterman)]

Sorry, read that wrong. The crash is in pyspf.

[John Neffenger (jgneff)]

I tried it on a third machine, and it's working there. The difference is as follows. On the machine that fails, the long AOL SPF records are being returned "malformed" and pyspf or its underlying support is failing -- perhaps by design -- to trying again with TCP.

On the machine that fails (ldc1042), I get:

john@ldc1042:~$ host -t txt aol.com
;; Warning: Message parser reports malformed message packet.
;; Truncated, retrying in TCP mode.
aol.com descriptive text "v=spf1 ... ptr:mx.aol.com ?all"
aol.com descriptive text "spf2.0/pra ... ptr:mx.aol.com ?all"

On the machine that works (gx110), I get:

john@gx110:~$ host -t txt aol.com
;; Truncated, retrying in TCP mode.
aol.com descriptive text "spf2.0/pra ... ptr:mx.aol.com ?all"
aol.com descriptive text "v=spf1 ... ptr:mx.aol.com ?all"

with no "Warning: Message parser reports malformed message packet" error. More importantly, I also get:

john@gx110:~$ python /usr/share/python-support/python-spf/spf.py 64.12.138.200 <email address hidden> imr-m06.mx.aol.com
('pass', 250, 'sender SPF authorized')

So now I need to figure out why my Hostway dedicated server would be getting a malformed DNS response by UDP.

Thank you,
John

[Scott Kitterman (kitterman)]

In this case what pyspf should be doing is returning a None result since it got no valid record back. Definitely shouldn't be crashing.

[Scott Kitterman (kitterman)]

The good news is I can make a crash at the same spot:

$ python /usr/share/python-support/python-spf/spf.py aol.com
Traceback (most recent call last):
  File "/usr/share/python-support/python-spf/spf.py", line 1621, in <module>
    print q.dns_spf(sys.argv[1])
  File "/usr/share/python-support/python-spf/spf.py", line 1010, in dns_spf
    a = [t for t in self.dns_txt(domain) if RE_SPF.match(t)]
  File "/usr/share/python-support/python-spf/spf.py", line 1045, in dns_txt
    return [''.join(a) for a in self.dns(domainname, 'TXT')]
  File "/usr/share/python-support/python-spf/spf.py", line 1150, in dns
    for k, v in DNSLookup(name, qtype, self.strict):
  File "/usr/share/python-support/python-spf/spf.py", line 105, in DNSLookup
    raise TempError, 'DNS ' + str(x)
__main__.TempError: DNS Timeout

The bad news is I reviewed RFC 4408 and TempError is the correct result. See http://www.openspf.org/RFC_4408#lookup.

I have asked someone who knows people in the Email area at AOL to see about compacting their record.

The DNS Timout error is tripped in the same spot, so I can fix your pyspf crash using that trigger.

[Scott Kitterman (kitterman)]

Looking into this further, when the TCP fallback just fails rather than producing a corrupt result, python-dns reports what it was able to extract from the UDP reply with no error indication. This is not good.

[Scott Kitterman (kitterman)]

You don't mention your configuration for the policy server in the bug report. You can set reject on temperror to false if you don't want these mails rejected in the mean time.

[John Neffenger (jgneff)]

I'm using the unmodified default configuration:

/etc/python-policyd-spf/policyd-spf.conf
----------------------------------------
debugLevel = 0
defaultSeedOnly = 1
HELO_reject = SPF_Not_Pass
Mail_From_reject = Fail
PermError_reject = False
TempError_Defer = False

In the meanwhile, I've just added "warn_if_reject":

main.cf
-------
smtpd_recipient_restrictions =
    ...
    warn_if_reject check_policy_service unix:private/policy-spf
    ...

I'm asking Hostway (my dedicated server provider) whether they know why I'm getting the error, "Message parser reports malformed message packet" on the UDP DNS response. I still get the error even with the firewall disabled. I don't get the error on other machines in other locations.

[Scott Kitterman (kitterman)]

Apologies. In upstream terms 0.4 is a long time ago (I'm also the upstream
developer for python-policyd-spf). 0.4 had a bug in it and that config
option doesn't actually work in that release. I'm trying to reconstruct how
I fixed it so I can give you a patch.

[Scott Kitterman (kitterman)]

Got it...

That version had two issues:

1. It would only use the config file if you explicitly explicitly call for it to do so. Otherwise it falls back to it's internal default configuration.

2. The internal default configuration was wrong and defaults to defer on TempError.

So, I believe if you change:

main.cf
-------
smtpd_recipient_restrictions =
    ...
    warn_if_reject check_policy_service unix:private/policy-spf
    ...

to:

main.cf
-------
smtpd_recipient_restrictions =
    ...
    warn_if_reject check_policy_service unix:private/policy-spf /etc/python-policyd-spf/policyd-spf.conf
    ...

(all on one line) it will use the config file and these messages won't get deferred. These are both fixed in Hardy already. You seem to have hit the perfect storm of problems here.

[John Neffenger (jgneff)]

You mean "master.cf", right? Putting the configuration file as an argument in "main.cf" caused Postfix to reject all mail with "451 4.3.5 Server configuration error."

/etc/postfix/master.cf
----------------------
# Python Sender Policy Framework (SPF) Service
# See <https://bugs.launchpad.net/bugs/205254>.
policy-spf unix - n n - - spawn
  user=nobody argv=/usr/bin/policyd-spf /etc/python-policyd-spf/policyd-spf.conf

That seems to do the trick! I faked an e-mail message from AOL and got this:

Mar 24 14:56:12 ldc1042 postfix/smtpd[26624]: connect from www.commspeak.com[63.229.3.151]
Mar 24 14:56:13 ldc1042 policyd-spf[26626]: :HELO client-ip=63.229.3.151; helo=www.commspeak.com; <email address hidden>; <email address hidden>;
Mar 24 14:56:13 ldc1042 policyd-spf[26626]: SPF Temporary Error: DNS Ran off end of data:Mail From client-ip=63.229.3.151; helo=www.commspeak.com; <email address hidden>; <email address hidden>;
Mar 24 14:56:13 ldc1042 postfix/smtpd[26624]: 390801400FF: client=www.commspeak.com[63.229.3.151]
...
Mar 24 14:56:13 ldc1042 postfix/smtpd[26624]: disconnect from www.commspeak.com[63.229.3.151]

No more "NOQUEUE: reject" on the SPF Temporary Error. I'm also receiving valid AOL messages now, too.

I'm waiting to hear back from Hostway about the "malformed" UDP DNS response.

Thank you,
John

[Scott Kitterman (kitterman)]

On Monday 24 March 2008 16:48, John Neffenger wrote:
> You mean "master.cf", right? Putting the configuration file as an
> argument in "main.cf" caused Postfix to reject all mail with "451 4.3.5
> Server configuration error."

Yes. Additionally I'm preparing an upload now so that python-spf will
properly retry with TCP if it gets a truncated reply in UDP. It'll also
catch the crashes when errors happen from the command line calls.

Glad to hear we're making progress.

[Scott Kitterman (kitterman)]

After digging through the python-dns object model for a good part of today, I discovered that python-dns passes enough information back to pyspf for pyspf to manage this without python-dns changes.

[John Neffenger (jgneff)]

Here are a few scenarios you may want to consider.

There seems to be a wide variety of responses you can get back when trying to get long or multiple DNS TXT records -- especially through a NAT router where you're forwarding port 25 onto an internal mail server. The machines behind the routers below are getting DNS from the routers, which proxy normal UDP DNS requests (not TCP, and sometimes not TXT requests) to their upstream name servers (obtained by DHCP).

(1) Machine behind router #1:

$ host -t txt aol.com
;; connection timed out; no servers could be reached

(2) Machine behind router #2:

$ host -t txt aol.com
;; Truncated, retrying in TCP mode.
;; Connection to 192.168.0.1#53(192.168.0.1) for aol.com failed: connection refused.

(3) Machine behind router #3:

$ host -t txt aol.com
aol.com descriptive text "spf2.0/pra ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ip4:64.12.143.99/32 ip4:64.12.143.100/32 ip4:64.12.143.101/32 ptr:mx.aol.com ?all"

$ host -t txt aol.com
aol.com descriptive text "v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ip4:64.12.143.99/32 ip4:64.12.143.100/32 ip4:64.12.143.101/32 ptr:mx.aol.com ?all"

Notice that it randomly gets one or the other of the two possible TXT records without any errors, but it never gets both.

(4) Machine with direct connection (no NAT router):

john@ldc1042:/etc/postfix$ host -t txt aol.com
;; Warning: Message parser reports malformed message packet.
;; Truncated, retrying in TCP mode.
aol.com descriptive text "v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ip4:64.12.143.99/32 ip4:64.12.143.100/32 ip4:64.12.143.101/32 ptr:mx.aol.com ?all"
aol.com descriptive text "spf2.0/pra ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ip4:64.12.143.99/32 ip4:64.12.143.100/32 ip4:64.12.143.101/32 ptr:mx.aol.com ?all"

That's the one at Hostway with the "malformed" response which started all this. It seems as more things get stuffed into the DNS TXT records, this could become more of a problem.

Thanks,
John

[Scott Kitterman (kitterman)]

pyspf 2.0.4-3 is uploaded to Debian. Once it's in Debian, I'll ask to have it sync'ed into Ubuntu. I've also discussed with the other upstream maintainers and this patch will be included in the next upstream release. Once this fix is released (for Hardy), pyspf will either provide a complete, consistent result or raise an error.

[Scott Kitterman (kitterman)]

I think all of those are considered now except that it will still error out on
the malformed packet. I'm not sure an automatic fallback on error is the
right answer.

The patch that's coming looks to see if the truncate flag is set and retries
if it is. The inconsistent behavior you saw was because the truncate flag
was being ignored and pyspf tried to process whatever information python-dns
managed to return.

[John Neffenger (jgneff)]

Hostway had me switch over to two name servers running BIND (instead of DNSCACHE) in my "/etc/resolv.conf" file, and now the AOL SPF checks are working as expected:

Mar 28 13:45:28 ldc1042 policyd-spf[4559]: :HELO client-ip=63.229.3.151; helo=www.commspeak.com; <email address hidden>; <email address hidden>;

Mar 28 13:45:29 ldc1042 policyd-spf[4559]: access neither permitted nor denied:Mail From client-ip=63.229.3.151; helo=www.commspeak.com; <email address hidden>; <email address hidden>;

I also no longer receive the error message, "Message parser reports malformed message packet," when getting the DNS TXT records from the command line:

john@ldc1042:~$ host -t txt aol.com
;; Truncated, retrying in TCP mode.
aol.com descriptive text "spf2.0/pra ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ip4:64.12.143.99/32 ip4:64.12.143.100/32 ip4:64.12.143.101/32 ptr:mx.aol.com ?all"
aol.com descriptive text "v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ip4:64.12.143.99/32 ip4:64.12.143.100/32 ip4:64.12.143.101/32 ptr:mx.aol.com ?all"

John

[Kevin Kelker (kk89)]

We are experiencing a "Temporary DNS error: DNS Ran off end of data" error with some SPF queries even with python3-spf 2.0.12t-3 on Ubuntu 18.4.1 LTS (see https://answers.launchpad.net/ubuntu/+source/pyspf/+question/697438).

The affected domains seem to have in common, that a dig query fails in UDP but is successful in TCP fallback (or directly using +tcp). Any hints would be highly appreciated!

> /usr/lib/python3/dist-packages/spf.py web.de
Temporary DNS error: DNS Ran off end of data

> dig web.de IN TXT
;; Warning: Message parser reports malformed message packet.
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.11.3-1ubuntu1.12-Ubuntu <<>> web.de IN TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6712
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;web.de. IN TXT

;; ANSWER SECTION:
web.de. 34 IN TXT "g6ftbncmryg0y6h956jfd242s1z9tndk"
web.de. 34 IN TXT "facebook-domain-verification=ksd7xc6g15rm7xkdga4qcm9hasgkny"
web.de. 34 IN TXT "Trustpilot-Verification-kqvVskCm6JQ9Vg1qAmahpBSJ5tvZORbriFyVIk4E"
web.de. 34 IN TXT "google-site-verification=No4jlUg2OIV7IsI2UF0v792Q8HgI9Brnp7qary1nMAQ"
web.de. 34 IN TXT "_telesec-domain-validation=D9B9D9DCF94742C07349C556E427C5A2EFFD85A67E1AC64190C473088D583370"
web.de. 34 IN TXT "_telesec-domain-validation=283146_2021-04-13_3lZFRx1xmMIgOTBxEGpHAM3qQ9wdpEVvDMuSs7NxCYi5xzD2jh"
web.de. 34 IN TXT "v=spf1 ip4:212.227.126.128/25 ip4:212.227.15.0/25 ip4:212.227.17.0/27 ip4:217.72.192.248/29 ip4:82.165.159.0/26 ip4:217.72.207.0/27 ip4:217.72.192.64/26 ip4:82.165.229.130 ip4:82.165.230.22 -all"

;; Query time: 1 msec
;; SERVER: xxx
;; WHEN: Mon Jun 07 13:31:41 CEST 2021
;; MSG SIZE rcvd: 718

> dig web.de IN TXT +tcp

; <<>> DiG 9.11.3-1ubuntu1.12-Ubuntu <<>> web.de IN TXT +tcp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43151
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;web.de. IN TXT

;; ANSWER SECTION:
web.de. 297 IN TXT "g6ftbncmryg0y6h956jfd242s1z9tndk"
web.de. 297 IN TXT "facebook-domain-verification=ksd7xc6g15rm7xkdga4qcm9hasgkny"
web.de. 297 IN TXT "Trustpilot-Verification-kqvVskCm6JQ9Vg1qAmahpBSJ5tvZORbriFyVIk4E"
web.de. 297 IN TXT "google-site-verification=No4jlUg2OIV7IsI2UF0v792Q8HgI9Brnp7qary1nMAQ"
web.de. 297 IN TXT "_telesec-domain-validation=D9B9D9DCF94742C07349C556E427C5A2EFFD85A67E1AC64190C473088D583370"
web.de. 297 IN TXT "_telesec-domain-validation=283146_2021-04-13_3lZFRx1xmMIgOTBxEGpHAM3qQ9wdpEVvDMuSs7NxCYi5xzD2jh"
web.de. 297 IN TXT "v=spf1 ip4:212.227.126.128/25 ip4:212.227.15.0/25 ip4:212.227.17.0/27 ip4:217.72.192.248/29 ip4:82.165.159.0/26 ip4:217.72.207.0/27 ip4:217.72.192.64/26 ip4:82.165.229.130 ip4:82.165.230.22 -all"

;; Query time: 1 msec
;; SERVER: xxx
;; WHEN: Mon Jun 07 13:32:29 CEST 2021
;; MSG SIZE rcvd: 718

Best regards & thanks in advance!
Kevin

[Steve Langasek (vorlon)]

You are responding to a fixed bug from 2008. Please file a separate bug report for your issue.