In
<Pine(_dot_)LNX(_dot_)4(_dot_)44(_dot_)0508022112580(_dot_)10651-100000(_at_)bmsred(_dot_)bmsi(_dot_)com>
"Stuart D. Gathman" <stuart(_at_)bmsi(_dot_)com> writes:
BTW, is an infinite include loop a PermError before it is evaluated?
I believe the answer is "no". A PermError due to either exceeding the
number of mechanisms or due to missing domains in an include: are not
caught until the given mechanism is executed. I'm not sure that this
is the absolute best thing to do, but I think this is matches existing
practice and previous drafts.
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.
I don't think you actually save much by detecting the infinite loop on
the second include. All the DNS records are going to be in your
resolver cache and you would have executed 6 of the 10 mechanisms
already. Considering how rare this *should* be in practice, I suspect
that doing the infinite loop detection on each mechanism all the time
will be a net loss in efficiency.
Of course, I think being spec-complaint is more important anyway,
but...
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)?
I would say that this behavior does not match the spec.
Now, if this was the worst violation of the spec in all of the SPF
implementations, I would be *very* happy.
-wayne