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)
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!
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:
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.
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
Cheers,
James
--
James Couzens,
Programmer
^ ( ( (
((__)) __\|/__ __|+|__ '. ___ .'
(00) (o o) (0~0) ' (> <) '
---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo---
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7A7C7DCF
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in Atlanta features
SPF and Sender ID.
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
signature.asc
Description: This is a digitally signed message part