In <20051029204343(_dot_)GC5857(_at_)ergens(_dot_)op(_dot_)het(_dot_)net> Alex
van den Bogaerdt <alex(_at_)ergens(_dot_)op(_dot_)het(_dot_)net> writes:
If this would have happened, I guess there's a good chance we
would have agreed on "v=spf[0-9\.a-zA-Z]* being reserved for
SPF and its version, and all other characters being syntax error.
I think this was discussed back in early 2004 and the general opinion
back then was that any future standard could define new SPF version
strings any way they want.
I also think you could pretend that has happened if you wish to
warn those others.
Sure, pretend there is a "too close to SPF records" standard that
excludes various TXT records that are too similar. You just can't say
that it is "SPF".
People talked about creating things like "v=spf1-test", or
"v=spf1-mfrom" records to denote other, SPF-like records.
example2.com IN TXT "v=spf1-all"
example2.com IN TXT "v=spf1 -all"
[...]
example2.com would result in no error.
That's a nice case for SPF test suites. Bye, Frank
As is the equivalent "v=spf1" "-all". By the way, isn't there a
chance that this doe not end up as "v=spf1-all" but could it also
end up as "-allv=spf1" if the strings are long enough?
While I have never been able to find anything explicitly in the RFCs,
to the best of my knowledge, all name servers and resolvers keep the
order of substrings within a single TXT record the same. It would be
a lot of work for them not to. This is completely different from
having multiple TXT records, which *do* often change order.
-wayne
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
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