Scott Kitterman wrote:
Personally I'm more interested in getting SPF v 1 standardized and out of
experimental status. I suspect we can work on both in parallel as long as
we are clear to keep them cleanly separated.
The key distinction as I see it is SPF v 1 updates MUST be backwards
compatible, while SPF v 3 has more freedom to innovate.
IMHO, v3 MUST be backward compatible.
I don't see the point of changing v1: it is rfc4408. A new version has
to be marked as such. If we introduce any new feature, or slightly
change the meaning of an existing feature, anyone willing to change
existing record can change the version number as well. OTOH, anyone
who interprets existing v1 records, is better off sticking to v1
specification.
I don't think there is much freedom to innovate with v3. SPF checks
will be carried out by old and new software alike, and I don't think
it is a Good Thing that the results vary widely. SPFv3 can just work
on the SPF RR type, recommending that a corresponding TXT record
tagged spfv1 be still maintained. Old rfc4408-software should discard
new SPF RRs starting with "v=spfv3" according to step 1 of section
4.5, and then proceed with "v=spfv1" RRs, probably but not necessarily
of type TXT, if any. New software should try TXT if it finds no SPF
RR, and accept "v=spfv1" for backward compatibility, but there is no
need to consider RRs of type SPF that start with "v=spfv3" (I think
that's what Stuart meant by "exclusively".)
IMHO, we should publish a single new RFC that prescribes a behavior
that is backward "compatible", for some acceptations of "compatible",
with both spfv1 and SenderID. We'll have to check with someone at the
IESG how many changes would be allowed for aiming at standard track,
but we have first of all to consolidate the existing use cases, which
may limit the amount of changes that would make sense to introduce.
I've had a try at publishing that wiki page, using the text above, see
http://www.openspf.org/Community/SPFv3
I haven't been able to create an SPFv3 subfolder. Navigating back from
a feature page to the SPFv3 URL just above is a bit of a nuisance.
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com