Re: [spfbis] RFC7208 4.6.4 Interpretation - MX Lookup Count Inconsistencies

[Scott Kitterman <[e-mail]>]

On Sunday, January 15, 2023 6:17:34 PM EST Jan Schaumann wrote:
> Scott Kitterman <[e-mail]> wrote:
> > There is the "overall" limit.  The count against the overall limit is two
> > ('a' and 'mx').
> 
> Thanks for clarifying.
> 
> I find this _very_ counterintuitive, fwiw.
> 
> My logic was roughly:
> 
> "Well, the limit should limit how many lookups I have
> to make in the worst case before I can decide.  Doing
> an 'mx' lookup by itself doesn't help me at all in
> making that decision -- I absolutely _have_ to turn
> any hostnames I get into IP addresses, so I must
> necessarily perform additional lookups."
> 
> So if I'm at a DNS lookup limit of 9 when I reach the
> 'mx' part, and the domain has 10 MX records, I perform
> 10 additional lookups (which don't count to the total
> limit, meaning I perform a total of 19 lookups) and
> move on.
> 
> But if I'm at a DNS lookup limit of 0 when I reach the
> 'mx' part, and the domain has 11 MX records, then the
> 'mx' evaluation yields permerror and I abort.
> 
> But if that's what it is, then that's what it is. :-)

That's what it is.  It probably made more sense in 2005 than it does now, but 
we're pretty well stuck with it for v=spf1.

It's actually even more complex than this since most will do a PTR lookup for 
each IP address returned.  Also, note that the limits for the SPF PTR 
mechanism as slightly different.

There were claims made at the time that there were other, easier ways to 
conduct DNS amplification attacks and the limits were overly strict.  That's 
certainly true now.  Even so, the pre-RFC limits were strictly based on 
maximum recursion depth and had the potential for truly extraordinary 
amplification.  Given the two, I think we picked the better approach in 2005 
and SPFbis was correct not to fundamentally change them.

If I were going to do an SPFv3 (I have no plans, don't get excited), this is 
one of the areas that would be ripe for redesign.

Scott K