Re: [spfbis] Fwd: RFC 7208 SPF - 4.6.4. DNS Lookup Limits increase

[Scott Kitterman <[e-mail]>]

As others have mentioned, there's no way to change this without substantial 
backward compatibility issues.  As John suggested, if we were doing this 
today, we'd do it differently.

Absent a general push for an SPF revision, it is what it is.

There are a few other things I would suggest we change if we ever do a SPF v3, 
but without a significant level of community interest to develop and field it, I 
think it's not going to happen, so you have to find ways to live within the 
current limits.  So far, whenever I've looked into specifics for someone I've 
always been able to find a way to do so.

Worst case you use a DNS with an appropriate data base driven back-end and use 
exists: with macros.  That can cover anything (although due to caching 
limitations it doesn't scale super well).

Scott K

On Friday, April 22, 2022 2:25:54 AM EDT Simon Gnieslaw wrote:
> Sending here because I got not reply to this last year.
> 
> ---------- Forwarded message ---------
> From: Simon Gnieslaw <[e-mail]>
> Date: Tue, 16 Mar 2021 at 20:05
> Subject: RFC 7208 SPF - 4.6.4. DNS Lookup Limits increase
> To: <[e-mail]>
> 
> 
> Hi there Scott,
> I am just contacting you in regards to your RFC which was published. An
> "Request for Comment" would mean that you actually want comments on it? I
> have never commented on an RFC before so please excuse me if this is not
> the correct procedure, please direct me to the right place if emailing you
> directly is not the right way.
> 
> Basically I just have a small issue with "4.6.4.  DNS Lookup Limits"
> limited to just 10 lookups.
> 
> I have run across a major Australian ISP who has actually started enforcing
> the limit of 10 to be able to send to their users, believe it or not. I
> have never seen this enforced before, and they are standing by it because
> technically that is the spec.
> 
> Many online tools which check for SPF record validity don't even see > 10
> lookups as a problem (i.e. The Microsoft 365 DNS record checker) and all
> the email services which I have come across before handle it without issue.
> 
> I would suggest that the limit of 10 is too low of a number in 2021.
> Consider that DNS servers and infrastructure is more robust now than what
> it used to be, given increased computational power, and the rise of free
> and paid DNS tools to offload the task on both client and server end such
> as Google's Free DNS, Quad9, Cloudflare 1.1.1.1, OpenDNS, DNS-over-HTTPS,
> and others, plus tools to host such as Cloudflare, Google Cloud Amazon
> Route 53, Azure, and others, so we do not need to be as conservative with
> the number of lookups as we used to be.
> 
> Increasingly, more and more services are requiring addition of SPF records
> to work properly, and they make a lot of use of the include: statements, as
> they have to cover a diverse range of IP addresses in both ipv4 and ipv6
> and their servers become distributed, ephemeral, and subject to change.
> 
> Systems include most notably Microsoft 365 and Google Workspace, and it is
> common to require SPF records for both to be in place at once during a
> transition or permanent split-delivery, plus a range of systems used for
> newsletter sending (Mailchip, Sendgrid, etc.), transactional email sending
> (i.e. have some Forum software installed or the website app itself),
> Helpdesk software (i.e. Zendesk), Bookkeeping software (i.e. Xero,
> QuickBook Online), CRM software (i.e. Salesforce), the list goes on and on,
> including multiples of the same time during a transition or large
> businesses with many departments.
> 
> I would suggest some sort of update to that standard, perhaps something
> along the lines of 10 lookups per root level include: and that each 3rd
> party service should only provide one root level include: statement, to try
> and keep them in check from going overboard.
> 
> As many popular services use the same include: record, it shouldn't be too
> hard for spam filters to Cache that include: if performance is an issue for
> them.
> 
> Minimum increase should be to 20, to account for doubling of records due to
> ipv6. But realistically, if sites are to expand then I think that 100 is
> more reasonable, especially if each root include: is limited to 10 sub
> lookups then that would allow for 10 services to run off the one domain.
> 
> What do you think?
> 
> Kind Regards,
> Simon Gnieslaw