-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Stuart
D. Gathman
Sent: Tuesday, August 02, 2005 9:23 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Broken SPF Records Update
On Wed, 3 Aug 2005, Alex van den Bogaerdt wrote:
domainsite.com._spf.name.com SPF "v=spf1
mx:domainsite.com ... -all"
name.com SPF "v=spf1 mx ...
include:domainsite.com._spf.name.com -all"
I think my solution is much more elegant and workable.
Have you read the entire thread?
I didn't recognize at first that the problem was two SPF domains
including each other (for a potential infinite loop). I thought the
problem was an SPF domain including a non-SPF domain.
BTW, is an infinite include loop a PermError before it is evaluated?
Consider this SPF pair:
a.com SPF "v=spf1 a mx include:b.com"
b.com SPF "v=spf1 a mx include:a.com"
In my SPF implementation, this will pass if the IP matches
any A or MX records for either a.com or b.com. Otherwise, it
results in PermError (infinite recursion). Since the PermError
is detected immediately upon seeing the second include, it is
efficient.
Are you sure, using strict on the validator these records tripped on the
processing limits, not on the recursion code.
I could see this being intentional.
Now, consider this record:
example.com SPF "v=spf1 a mx include"
Currently, my implementation immediately gives PermError for the trivial
recursion. BUT, suppose the publisher intended that
the record pass if IP matches A or MX, otherwise result in PermError
(causing the mail to be rejected)?
Good point. Maybe it ought to go at least once through the record. The
trivial recursion detection is a good check for the validator, but maybe not
for operations. Maybe this should be a harsh mode only check. This record
will quickly permerror on processing limits in any case.
Scott K