--"Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com> wrote:
Personally I find the current prefix highly idosyncratic. I
would have made it
"SPF:1.0" to signify "this is an SPF record, version 1.0"
It is not a version indicator. It is simply a discriminator.
There will be an SPF 1.1, 1.2, 2.0 etc. but there is very little
probability that the indicator will ever change.
The behavior arround unknown mechanism should probably be thought through
a bit.
Unknown mechanism = error is not the best approach if you want
extensibility.
I'm going to agree with Julian on this one. The syntax and the protocol
are both indicated by the "version" tag "v=spf1". This provides an
assurance to anyone choosing to implement it now that their domain won't
break mysteriously down the line.
"Unknown mechanism = error" provides an assurance of stability, at the
expense of denying small incremental changes. BUT, what choice do we
realistically have? If you receive a mail message and go to look up its
SPF record and find "v=spf1 a mx mystery:4C57E6F8 -all" then what is the
proper behavior for the unknown mechanism? Is it proper to skip over the
mechanism and (usually) reject the mail since you don't understand the new
mechanism? Is it proper to assume that the unknown mechanism *might* have
authorized the mail (if we could understand it) so we should let ALL mail
through?
The only way I see to get around "Unknown mechanism = error" is to provide
something similar to if-then-else so that old parsers can still follow the
domain owners' wishes when parsing "extended" SPF. You have to be able to
100% specify or 100% predict the behavior of the old code when it is faced
with the new extension it doesn't grok. Unfortunately that's hard to do
when the language is designed for a 1-line message. If the change is large
enough that you don't want old parsers to even try to interpret it, then I
think publishing both v=spf1 and v=spf2 is the best answer for now.
Unknown modifier=skipped is in my opinion a neutral tradeoff. You could in
theory use new modifiers to accept or reject based on new ideas.
The big 6 definitely want extensibility. If SPF as currently written does
not give it to them, they will either rewrite SPF or they will chose
something else.
Remember that if SPF goes into any form of standards process everything is
on the table for negotiation. That is one reason to avoid starting a
standards process, uncertainty is not a plus.
But the industry is going to demand extensibility, that is the way that
the system works.
MS uses the extensibility argument to claim that XML is superior.
Unfortunately their spec was plagued by the same problem: what the old code
should do when it meets new data is not spelled out in the spec. This is
IMO worse than v=spf1 -- if you start to use a new mechanism (and start to
rely on it) you still have no control over what the old parsers will do.
At least with v=spf1 and v=spf2 you have a clear indication that there is a
new mechanism in use, and the v2 parsers can use it, while v1 parsers will
have a clear fall back position.
I would be happy to support extensibility as long as there is a clearly
defined behavior for the old code meeting the new/unknown data. Something
like "v=spf2 a mx unknown=skip domainkeys:%{d}.yahoo.com unknown=fail
foo:bar -all" maybe?
I expect there will be more wrangling when it comes time to approve it as a
real RFC, and that we probably have to do that before SPF becomes a real
DNS record type. Maybe it will not even be called SPF by that point. That
would probably be a good time to build in extensibility as an
honest-to-goodness requirement. But I don't think that should stop people
from using v=spf1 now...
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>
-------
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.7.txt
Wiki: http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡