James,
Thank you for your answers, however, I'm not clear in some cases that you
were addressing the questions I asked.
At 12:55 PM 10/20/2004, you wrote:
On Wed, 2004-10-20 at 10:49, Commerco WebMaster wrote:
> SPF List Members,
>
> I had sent a message out to the list last week and since have attempted to
> contact several SPF testing sites per some feedback to last week's message
> in an effort to do the right thing. Thank you to those who responded with
> guidance for me on my earlier message.
I did not receive or notice such a message (I am the caretaker for
spfTools.net formerly spf.infinitepenguins.net)
Posted the original "Managing exploits" message last week. I had sent a
message regarding some issues and inputs I had with and for spfTools.net a
while back and received no response, so did not know that you were the
individual managing that. Sorry.
> An event last week started me thinking about recursion in redirect=
statements.
>
> I do not recall reading this in the spec itself, so I thought I would
bring
> it up here. Might it be a good idea to explicitly define and limit the
> number of levels of recursion that a checker of SPF records must go
through
> before failing as part of the SPF specification?
Its very blatantly stated!
Actually, the section 5.2 you quote below seems to deal with the issue of
include, not redirect= - I did not know that we could presume the same
things for both there. Perhaps that should be explicitly stated in the
specification document, if I have not misread the section.
Section 5.2:
> Note: during recursion into an Include mechanism, explanations do not
> propagate out. But during execution of a Redirect modifier, the
> explanation string from the target of the redirect is used.
Section 6.2:
Did not notice the Redirect modifier mentioned in this section - thank you
for pointing this out to me.
> 6.2 Processing Limits
>
> During processing, an SPF client may perform additional SPF
> subqueries due to the Include mechanism and the Redirect modifier.
>
> SPF clients must be prepared to handle records that are set up
> incorrectly or maliciously. SPF clients MUST perform loop detection,
> limit SPF recursion, or both. If an SPF client chooses to limit
> recursion depth, then at least a total of 20 redirects and includes
> SHOULD be supported. (This number should be enough for even the most
> complicated configurations.)
>
> If a loop is detected, or if more than 20 subqueries are triggered,
> an SPF client MAY abort the lookup and return the result "unknown".
>
> Regular non-recursive lookups due to mechanisms like "a" and "mx" or
> due to modifiers like "exp" do not count toward this total.
> If this is done, should another possible published override value be
> available for SPF publishers to let a publisher with any legitimate reason
> to exceed the aforementioned recursion limit do so?
No. It should NEVER EVER EVER be up to a publisher. This is because
the publisher could be an asshat and intentionally publish a broken
record resulting in finite levels of recursive checking.
Agreed, though perhaps we should keep the colorful characterization
language down when posting to the list.
> Also, would it be wise to consider a recursive chain broken at any
point in
> the chain where a redirect= statement ends up looping back to an existing
> earlier chained redirect= domain, also making that recommendation an
> explicit part of the specification? e.g.,
>
> BAR DNS ZONE EXCERPT -
> bar.tld. IN TXT "v=spf1 redirect=_spf.foo.tld"
>
> FOO DNS ZONE EXCERPT -
> foo.tld. IN TXT "v=spf1 redirect=_spf.bar.tld"
>
> I think that the above would cause a looped checking scenario if not
> properly addressed someplace in code.
Please see my post to this list last week:
http://www.gossamer-threads.com/lists/spf/discuss/13029?search_string=achtung;#13029
The message link offered above is a darned good one about the problems a
publisher had with properly implementing the include mechanism in their SPF
DNS TXT record. Now then, do you think that we should publish anything in
the specification about what I mention above for the redirect modifier?
Cheers,
James
--
James Couzens,
Programmer
Best,
Alan Maitland
The Commerce Company - Making Commerce Simple(sm)
http://WWW.Commerco.Com/