Re: [spf-discuss] Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

[Douglas Otis <[e-mail]>]

On Aug 26, 2005, at 12:56 PM, wayne wrote:

>
> In <[e-mail]> Douglas  
> Otis <[e-mail]> 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








_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf