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.
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?
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?
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.
Leaving along honest configuration errors, I could see people who don't
care much for what SPF is attempting to accomplish trying to break SPF
processing by causing infinite loops deliberately in their published
records, so having some sanity check in place to limit damage from
malicious recursive lookups formally defined in the specification is
probably appropriate. I think that helping people by pointing out areas to
consider when both publishing and implementing is already part of the
specifications, this just extends to two small areas I see that may not be
covered in the spec today.
Finally, perhaps it is just me, but as late I believe that I am seeing far
more messages on the politics of SPF and not messages focused toward
building the core specifications for SPF on this list. I am hopeful that
SPF does not become mired in political battles which stop the project from
moving forward entirely.
A lot of people have invested time and work in publishing SPF records and
ultimately expect their efforts to result in a solid specification that
works to combat the problem of domain name identity theft in email messages
and to protect the reputation of their domains by not having them
associated with unseemly UCE email messages carrying their stolen name
identity.
If a new proposed specification addition does break what I think was the
original objective for SPF (to verify if the from party in an email message
being sent is really sending from a place the domain operators allow in
order to protect the identity and reputation of their domain), perhaps it
should have no business being a part of SPF, but rather should get its own
separate specification or be dropped entirely.
I know most people on this list are sincere in their desire to birth the
SPF spec, so please let us set aside things which amplify
politics. Instead, let us focus on the problem of maturing the
specification to general benefit of and acceptance by the Internet
community at large.
Best,
Alan Maitland
The Commerce Company - Making Commerce Simple(sm)
http://WWW.Commerco.Com/