On Sun, 2004-10-31 at 21:09, Greg Connor wrote:
--Mark Shewmaker <mark(_at_)primefactor(_dot_)com> wrote:
Well. If all the existing, published, running code has to change, that's a
tall barrier. At that point it makes little difference whether you change
the number, I think.
[...]
I agree that this is (slightly) better than scoping with modifiers, but
still has the same problem. We are changing the spec out from under folks
who have published working code.
Programmers whose libraries only read's TXT records, (ie, all of them),
could ignore these changes in the spec if they didn't care about
additional scopes, (and don't care about not-recommended record
formats.)
The code is going to have to be updated when RR's are allocated anyway.
Until then, currently-deployed code is compatible with my suggestion's
recommendations.
Current code only has to be updated to:
1. Understand new RRs.
2. Understand non-mailfrom scopes.
3. Understand non-recommended records that are not currently published
anyway. (And if that one's a problem, the modification could change
to require those recommendations.)
I don't really have a strong preference as to whether scope is a modifier
or a macro, but I do have a strong preference to not retroactively change
the v=spf1 spec. Whether domain owners have to change, or library writers
have to change, or both, it doesn't much matter; we are changing a working,
production spec out from under them.
Right now there is tension between two record formats (spf1 and spf2.0),
and the later's implicit use of the current spf1 record format. Making
a small, backward-compatible change in the spf1 format to accommodate
other scopes means that we could fold in MS's PRA-scope interests within
a tweaked spf1 format and avoid needless antagonism.
1. We gain because it becomes less likely that MS will continue to
feel a need to tell people to use a 2.0 format that presumes
defaults for long-published records that weren't originally
intended, (causing the long-time publishers to be more likely
perceive that we've pulled the rug out from under them.)
2. MS gains because they can publish records in a format that the SPF
community won't complain about.
3. The spec allowing (but not recommending) a "pra/mfrom" scope gives
a similar compromise as the softfail result. It allows MS the
option of publishing single-records with combined scopes, at the
risk that existing libraries will ignore those records.
It's an allowance that lets us not appear to be horribly rigid.
In practice, either people won't publish single-record
combined-scopes like that, in which case this isn't an issue,
or people do publish them in droves, which gives us the same
situation as would be the case now if MS were to convince
millions of domains to publish dual-scoped 2.0 records tomorrow.
(If MS were to do that now, I would guess that current coders
would soon update their libraries to read those records in the
published mfrom scope.)
Why not just call it spf2 if you are
going to change the rules?
I see no need to change the version number for mostly
backward-compatible changes, given that:
1. The changes would not affect the interpretation of any
currently-published records.
2. For any possible records for which the current mailfrom scope could
not be read with current libraries, there is an alternative form
a publisher is recommended to use which could be read by both
current and updated libraries.
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com