Phil Howard [phil-spf-discuss(_at_)ipal(_dot_)net] wrote:
How about "v=spf1+" meaning "experimental additions" to version 1, and
that such a record can co-exist with "v=spf1" so you can publish a
normal specification at the same time?
@ IN TXT "v=spf1 ip4:10.0.0.0/8 -all"
@ IN TXT "v=spf1+ foo:bar ip4:10.0.0.0/8 ?all"
Greg Connor [gconnor(_at_)nekodojo(_dot_)org] wrote:
That's probably fine. Does the spec currently require v=spf1 to be
followed by a space? If the only requirement is v=spf1{anything} then
v=spf1+ might get accidentally picked up by some parsers. But if that
is the case then the same problem exists with v=spf10.
The spec wasn't clear on what would happen in future versions. The
second version will probably say something like "Look for TXT records
starting with v=spf2 - if none present, look for v=spf1 and continue
with that, in compatibility mode. Administrators should publish both
v=spf2 and v=spf1 records for [some recommended length of time]"
Meng Weng Wong [mengwong(_at_)dumbo(_dot_)pobox(_dot_)com] wrote:
What kind of version strings do you guys want to see? How do we make it
clear that a client at a certain version should or should not interpret
records of a certain version?
[...]
I'm interested in the extensibility thing --- suppose a domain wants to
say
I do both designated-sender and DK authentication. I already have the
DS stuff in there, but now I want to be able to experiment with DK. I
want to publish two forms of records, so that clients that read DK
will only evaluate that, and not the IP.
I want to be able to say
v=spf1 a mx -all
v=spf1.x-dk dk -all
And clients that are x-dk aware would ignore the first line.
If we can unambiguously specify that version extensions are to be
ignored by strict spf interpreters, that leaves room open for
innovation.
I think the "+" idea leads into the right direction.
What about
v=spf1+dk1+x
? This would mean that, to be able to parse the TXT record, one's parser would
need to understand SPFv1 with the DomainKeys v1 and experimental (custom,
non-standardized) extensions (all of course being in SPF-compatible syntax).
So, a domain owner could specify multiple SPF records, providing the best
possible policy for most parser implementations out there. For instance:
v=spf1 mx a -all
v=spf1+dk1 mx a dk -all
v=spf1+x mx a foobar -all
v=spf2 mx a dk newspf2feature -all
v=dk ...
(the last record being a non-SPF DomainKeys record which is to be interpreted
neither by SPFv1 nor SPFv2).
The "x" extension would mean "interpret at your own risk", that is, be
experimental, custom, and non-standardized. I currently fail to see the
usefulness of such an extension, though.
As for the syntax, we could also use "v=spf1+dk1,x", or even "v=spf1:dk1,x".
It's probably a matter of taste.
All of this would require a central registry for SPF extensions.
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)���v¼����ߴ� �1I�-�Fqx(_dot_)com