Re: [spfbis] Local macros strike again, was Suggestion...

[Douglas Otis <[e-mail]>]

On 1/11/12 2:39 PM, Derek Diget wrote:
>
>  On Jan 11, 2012 at 17:17 -0500, Hector Santos wrote: =>Section 10.1
>  Processing Limits, covers the security idea of limits. But it =>only
>  mentions one hard limit of 10 for MX and PTR. It recommends a
>  unspecified =>minimum for others like INCLUDE which is more of a
>  concern because of its =>recursive nature. We have a limit of 20
>  here. Probably more than enough to =>allow a domain to general an
>  include recursion level of 20! Each of these =>directive whether with
>  macros or not, needs to have limits. => =>So in my view, it will
>  probably be a good idea to avoid the "guessing game" =>and begin to
>  add semantics about specific recommended limits. => =>Doug is
>  suggesting of changing the 10 for MX/PTR to maybe 5. Where did 10
>  =>come from to begin with? I presume is what was some SMTP client
>  were already =>doing when sending out mail - they have a MX expansion
>  limit of 10. Maybe the =>10 come from the author's experience with
>  this.
Dear Hector,

This was simply explaining the impact caused by a change Wayne Schlitt 
made to host name limits in his SPF library.  He restricted the number 
of host names resolved to 5.  This caused a problem for t-online.de who 
never published SPF records but were subjected to "default" SPF records 
such as "a mx/24" and that had 8 hosts in their MX RRset, for example. :^(

The original concept was to permit any amount that could fit within any 
number of SPF records where only recursion was limited to 20.  Several 
expressed concern about the amount of traffic a recursion approach might 
cause.  Testing back in 2006 came across several libraries still using 
recursion as a limit, and some limiting hosts to the number returned 
within a single DNS transaction for a requested RRset, and the 5 host 
name limit used by Wayne instead of the 10 indicated in the draft.

>  I have been reading this thread and wanting to chime in...
>
>  I have always read the first sentence of the 3rd paragraph of RFC
>  4408 section 10.1 (starts with "SPF implementations MUST limit") to
>  mean that an SPF record that requires more that 10 DNS lookups to be
>  a PermError and the SPF library should not do a 11th lookup.
>  Period/end-stop.

Dear Derek,

The mechanism and modification limit is expressed in section 10.1
,--
SPF implementations MUST limit the number of _mechanisms_ and 
_modifiers_ that do DNS lookups to at most 10 per SPF check, including 
any lookups caused by the use of the "include" mechanism or the 
"redirect" modifier.
'-
Please note the term "mechanism" and not DNS transaction or imprecise 
lookup that might imply the existence of an intervening agent.  
"include" is a mechanism and "redirect" is a modifier that is counted as 
a mechanism.

The lookup limit expressed in section 5.4 "mx"
,--
This mechanism matches if <ip> is one of the MX hosts for a domain 
name.  MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ] check_host() 
first performs an MX lookup on the <target-name>. Then it performs an 
address lookup on _each_ MX name returned. The <ip> is compared to each 
returned IP address. To prevent Denial of Service (DoS) attacks, more 
than 10 MX names MUST NOT be looked up during the evaluation of an "mx" 
mechanism (see Section 10 
<http://tools.ietf.org/html/rfc4408#section-10>). If any address 
matches, the mechanism matches.
'--

Each "mx" mechanisms can separately invoke address resolution 
transactions over a maximum of 10 host names.  As the dos draft 
demonstrated, a compliant library processed 10 mechanisms  where each 
mechanism in turn induced 10 subsequent DNS transactions to resolve each 
host's IP address set.  Tallying these DNS transactions is 10 times ( 1 
mx rrset + 10 host/a) or 10 times 11 for 110.  Of course, one must 
include the first transaction for the initial SPF record.   This bring 
the total DNS transactions used to resolve a single email address to 
111.  This is no where near 10 many keep suggesting.

>  The MX limit that is mentioned in later paragraphs is still
>  constrained by the first sentence's (10 lookup) limit. I would
>  almost say that the 4th paragraph ('When evaluating the "mx"') is
>  redundant to the 3rd paragraph except for the mention of the %{p}
>  macro.
>
>
>  (I can't speak for code writers of the MTA we use, but I think that
>  is the behavior I have seen. 11 DNS lookup causes a PermError to be
>  returned by check_host() ).

Perhaps you were confused by the term mechanism.  A mechanism such as 
"mx" or "ptr" performs DNS transactions to obtain RRsets and then up to 
10 subsequent transactions for each element of the RRset.  In other 
words, 110 DNS transactions.  This is made more dangerous when 
transactions are based upon hosts defined by email-address local-parts.  
As such, it would be wrong to suggest SPF results are for the entire 
domain or that they can be cached.  The local-part concept runs afoul of 
Repute definitions or efforts to combine the different domain results.

Regards,
Doug Otis