On Aug 26, 2005, at 12:56 PM, wayne wrote:
In <6503D26C-DB8E-404D-8D8F-5087F64A9119(_at_)mail-abuse(_dot_)org> Douglas
Otis <dotis(_at_)mail-abuse(_dot_)org> writes:
If the goal of the SPF Classic draft was intended to capture a point
in time pre-dating semantic extensions related to RFC-2822 defined
content, then perhaps the draft should be on an historic track. ; )
RFC2026 says:
4.2.4 Historic
A specification that has been superseded by a more recent
specification or is for any other reason considered to be
obsolete is
assigned to the "Historic" level. [...]
This wouldn't apply because there are no newer specifications for SPF,
nor is it obsolete.
My apologies for this poor attempt at humor. With the authors
insisting the draft only documents prior art that is now in conflict,
it becomes difficult to consider this draft as experimental.
With an experimental draft, one would expect modifications addressing
issues as they arise. This record conflict has been a problem for a
long time. If this draft is really only for historical purposes,
perhaps SPF Classic should dropped. Sender-ID would then need to
introduce a different draft defining the syntax related to the DNS
records.
SPF Classic has not achieved the goal of capturing a pristine version
of pre-MARID semantics. With some semantic changes introduced by the
SPF Classic draft itself, [...]
There isn't a "pristine" version of SPF, there are several different
draft specifications and a whole bunch of implementation. There are,
unfortunately, conflicts between these. The SPF-classic I-D attempts
to document the most coherent intersection of these.
The reduction in processing limitations seemed substantial with
understandable reasons. There was a change that including HELO in
parallel with the MAIL FROM rather than when the MAIL FROM was NULL.
A number of other changes have since been struck. Problems created
when modifying record processing or what identifies are applied could
be ameliorated through use of record versioning. This would ensure
the server understood how to utilize the record being offered.
While I agree with the view that PRA semantics may create problems
when applied against the initial record version, the Sender-ID draft
permits the use of a scoped version of the record which makes it
clear what semantics are expected. Accommodating this identical
provision within SPF would have resolved the potential Sender-ID
conflict and also would have been a means to acknowledge adherence to
newer processing limits and HELO checking, for example.
Sender-ID does not define the syntax of the record, but instead
depends upon the SPF draft for these definitions. It would appear
the Sender-ID draft is willing to follow the syntax defined by the
SPF draft. The major difference is that Sender-ID accommodates both
versions of the record, whereas, despite the reasons, SPF has
deliberately elected not to support the scoped version.
This difference relates to a prefix of "v=spf1 ..." versus "spf2.0/
<scope>,<scope> ..."
While I'm sure that the SPF-classic I-D can be improved, I think it
has done a good job of meeting the goal of documenting SPF, as it
existed pre-MARID.
I understand this is the justification used for the draft then
ignoring the scoping problem. : (
Solutions:
a) Sender-ID avoids applying any RFC-2822 content semantics to the
initial DNS record version.
b) SPF incorporates support for a scoped version of the DNS record.
c) a & b
d) Drop SPF Classic and create a separate syntax document.
The number of domains publishing the initial version of the DNS
records negatively affected is likely less than those that benefit.
By itself, SPF is not without its own significant issues. Even
Hotmail publishes just the initial record version, but depends upon
the PRA. It would seem that while the SPF effort claims
guardianship, they have been guilty of versioning abuses as well.
Although option b is not perfect, it is good enough.
-Doug