Unable to parse long SPF record strings (again)

[coreequip]

Hi Adam,

thanks for this great lib! ありがとうございます！

I encountered a similar issue in #2, but this case is longer different. Section 3.4 of RFC 7208 states that an SPF record SHOULD not exceed 512 bytes, but this is only a recommendation, not a strict requirement.
Modern DNS infrastructure supports larger responses via EDNS0, so longer SPF records are generally supported, although shorter records are still recommended for compatibility.

Unfortunately, this is observed in the wild, thanks to Apple:

dig +short TXT me.com
"v=spf1 ip4:17.41.0.0/16 ip4:17.58.0.0/16 ip4:17.142.0.0/15 ip4:17.57.155.0/24 ip4:17.57.156.0/24 ip4:144.178.36.0/24 ip4:144.178.38.0/24 ip4:112.19.199.64/29 ip4:112.19.242.64/29 ip4:222.73.195.64/29 ip4:157.255.1.64/29" " ip4:106.39.212.64/29 ip4:123.126.78.64/29 ip4:183.240.219.64/29 ip4:39.156.163.64/29 ip4:57.103.64.0/18" " ip6:2a01:b747:3000:200::/56 ip6:2a01:b747:3001:200::/56 ip6:2a01:b747:3002:200::/56 ip6:2a01:b747:3003:200::/56 ip6:2a01:b747:3004:200::/56 ip6:2a01:b747:3005:200::/56 ip6:2a01:b747:3006:200::/56 ~all"

Please remove the 512-character limit. Otherwise, this library is no longer usable for real-world SPF records.

[Bas-Man]

Thanks for bringing this to my attention.

That is a really long string.

I will see if I can do something. But I also noted it is broken in to sections. I may not have supported that yet. I will need to add this test string and see what works or breaks.

[Bas-Man]

Taking a closer look. This is a poorly crafted SPF record.
It lacks the use of any form of "include:" statements.

[coreequip]

Yes, I know. Sad. But it's quite often in my outbox … because it's Apple. ¯\_(ツ)_/¯

EDIT: Just found another real world example: GoDaddy.

dig +short TXT spf-0.secureserver.net
"v=spf1 ip4:97.74.135.0/24 ip4:72.167.238.0/24 ip4:72.167.234.0/24 ip4:72.167.218.0/24 ip4:68.178.252.0/24 ip4:68.178.213.0/24 ip4:216.69.139.0/24 ip4:208.109.80.0/24 ip4:92.204.81.0/24 ip4:198.71.224.0/19 ip4:184.168.224.0/24 ip4:184.168.200.0/24 ip4:184." "168.131.0/24 ip4:184.168.128.0/24 ip4:92.204.65.0/28 ip4:182.50.132.0/24 ip4:173.201.192.0/23 ip4:72.167.168.0/24 ip4:92.204.71.0/24 ip4:132.148.124.0/24 ip4:72.167.172.0/24 ip4:188.121.52.0/24 ip4:188.121.53.0/24 ip4:52.89.65.132 ip4:54.214.222.76 ip4:54" ".184.82.65 ip4:52.26.164.15 ip4:68.178.181.0/24 ip4:50.63.8.0/22 ip4:208.109.194.0/24 include:spf.protection.outlook.com -all"

[Bas-Man]

Hi @coreequip, I haved increased the MAX_SPF_STRING_LENGTH from 512 to 1024 and confirm that this works.

You can build from git@github.com:Bas-Man/rust-decon-spf.git as I am not ready to make a full release. I am in the process of making other changes.
The biggest issue is that I am changing from Spf<String> to non generic for Spf. If this is an issue. I would suggest that you update your local fork so that you can contunue to work without addtional code changes.

I am leaving this ticket as open for now.

[coreequip]

Thanks, Adam. Your suggestion is the current "quick fix" I use as well. It hasn't hit the limits yet. However, IPv6 addresses are being used more frequently, which is understandable, so the SPF records are getting longer.

[Bas-Man]

Yes. It seems so. Hopefully the "include:" mechanism will be used correctly. As each included spf record expands the length overall.

There are some breaking changes coming in a future release. Specifically that I am removing the generic for Spf.

I do not have a time line for this. I will likely try and release a RC ON GitHub. I have a lot of documentation that needs to added.

[coreequip]

Great news! I'm looking forward to it, and I have notifications enabled. 😄