On Mon, 2004-11-01 at 10:23, Richard Bang wrote:
> I see no need to change the version number for mostly
backward-compatible changes, given that:
You must work for the MS library guys who gave us two DLL's of the same
version that were "Mostly compatible" but broke almost any app that wasn't
designed directly for that version.
Please point out exactly what this would break, especially in comparison
with the breakage that can occur with MS's current default of "if no
spf2.0 record, use spf1 record in pra scope."
We already have a back-door incompatible change going in given MS's
experimental draft. This small tweak of spf1 allows what MS wants to be
incorporated in the spf1 syntax, but yet maintaining backwards
compatibility with all currently-published records.
The alternatives as I see it are:
1. Confrontational and antagonistic, the "I dare you" approach:
Letting Microsoft fail to convince people to use spf1 records in
pra context in the long-term, by having it blow up in their face.
Whether MS fails and looks bad doing that or not, and whether some
of the blame for the problem is directed at us, the whole situation
looks like needless political infighting to outsiders, which may
well slow adoption over what could otherwise be the case. (I don't
know--this is a guess.)
2. Totally acquiescing by agreeing with the principles of Opt-out:
Tell mfrom-only publishers who don't want to their spf1 records
evaluated in mailfrom scope to create a additional million or so
records in oto opt out of pra scope by creating placeholder
spf2.0 records.
3. Political maneuvering that still doesn't let MS have the technical
solution they want:
Allow people to add pra scope to their spf records via an "op"
modifier, but don't allow for pra and mailfrom scopes
to differ.
4. Hold-your-nose solution: Positional modifiers.
This allows everyone to get what they want, at the expense of a
more difficult-to-read record.
I have to admit that I have to hold my nose at my own solution
too--I just think it's not quite as objectionable as positional
modifiers, and should be at least discussed.
It's a simple software rule.
NEW VERSION = NEW VERSION NUMBER
Users will have to update their spf records, its fact of life. That's the
whole point of version numbers.
Why should publishers have to update their records? With my proposal
they needn't do that.
Given the current MS spf2.0 experimental draft, they may feel they have
to update something, as well as feeling betrayed by the thought that
they need to update.
You know, if you add in the concept of an "op" modifier discussed
elsewhere, in a non-positional way, and requiring the use of it in TXT
records whose scope includes mailfrom, (as opposed to the
"v=spf1/mailfrom,pra " syntax), then this covers all bases:
1. Multiply-scoped TXT records that include mailfrom can be made with
just one record and yet be 100% compatible with both existing and
updated libraries.
2. Singly-scoped records other than the default scope of mailfrom and
multiply-scoped records not including mailfrom aren't handled by
current spf1 libraries anyway, so they don't present backwards
compatibility problems.
"If your scope includes mailfrom, add an "op" modifier to your record.
If your scope doesn't include mailfrom, start the record with
'v=spf1/scope1,scope2,... "
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com