RE: Appeal: Publication of draft-lyon-senderid-core-01 inconflict with referenced draft-schlitt-spf-classic-02

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



...... Original Message .......
On Fri, 26 Aug 2005 23:15:32 -0400 "John Glube" <jbglube@xxxxxxxxxxxx> 
wrote:

>"The conflict" apparently is that the Schlitt draft
>recommends against use of spfv1 records for use with PRA
>authentication, while the Lyon draft says that receivers
>can use the spfv1 records for use with PRA authentication
>and therefore senders need to ensure their spfv1 records
>are suitable for this purpose.

I think this misses the essentiatpoint.  There is an installed base of 
v=spf1 records published in some significant part before MARID.  Those 
records were published with Mail From and HELO and only with Mail From and 
HELO in mind.  The appeal is not just about what the Schlitt Draft 
(rightly) says.

>How did this conflict arise? It arose after the closure of
>MARID and prior to the filing of senderid-core-00. 
>
>Let's remember the scene. The open source community was up
>in arms over the IPR disclosure by Microsoft. At the same
>time America Online had publicly withdrawn its support for
>Sender-ID due to the lack of backward compatibility between
>spf2.0 and spf1.  
>
>Mr. Wong, over the strong objections of many within the SPF
>community, went ahead and negotiated an arrangement that
>allowed for the backward compatibility of PRA
>authentication with spfv1 records. [2]
>
>Further to this arrangement:
>
>* The Lentczner draft for spfv1, which only supported mail
>from authentication and the Lyon draft for spf2, which
>supported both mail from and PRA authentication were filed
>with the IESG. 
>
>* Both drafts flowed from MARID. 
>
>* The Lyon draft supported backward compatibility and in
>response America Online announced its continued support for
>Sender ID.
>
Thus conflicting with one of the few areas of MARID for which their was a 
rough consensus.  This back room deal should not be allowed to overturn 
working group rough consensus.

>* Microsoft published an SPF wizard which supported the
>publication of spfv1 records, subject to the need of
>publishers to be satisfied their spfv1 records could be
>used for both mail from and PRA authentication.
>
>Shortly afterwards, due in large measure to the anger and
>upset over Mr. Wong's management of the relationship with
>Microsoft and the resulting failure to fully separate the
>Sender Policy Framework from Sender ID after the collapse
>of MARID, the SPF Community elected a Council to run the
>affairs of the SPF Community. 
>
>In accord with its mandate, the Council proceeded to
>withdraw the Lentczner draft from the IESG and substitute in
>its place the Schlitt draft. 

I agree it was regarded as a substitute.  I don't think that was the 
intent.  The intent was to document existing (pre-MARID) practice and give 
up on MARID as a good try gone bad.

>The IESG was now faced with a situation where the Lyon
>draft, which had relied upon the Lentczner draft, both of
>which flowed out of MARD, was now relying on the Schlitt
>draft for its underpinning. 
>
Although it takes advantage of some lessons learned from MARID, the Schlitt 
draft is not a MARID product.  It documents the results of roughly two 
years of independent protocol development, experimentation, and deployment. 
 There are at least a dozen independent interoperable implementations in 
use today that result from these efforts.

>In turn the Schlitt draft re-introduced helo authentication
>based on historical usage and contains the recommendation
>which conflicts with the backward compatibility arrangement
>in the Lyon draft. [3]

HELO checking has long been a part of SPF.  The HELO identity was never 
addressed by MARID and so it's not surprising it wouldn't be in MARID 
drafts.

>Since neither side was prepared to budge, the IESG
>ultimately allowed both drafts to proceed forward as
>experiments, with very strong disclaimers.
>
>Now the IESG is faced with an appeal from its decision to
>allow publication of the Lyon draft based on the conflict
>with the Schlitt draft.

Based on the conflict with the intended usage of record publishers.  There are reasons the 
Schlitt draft says what it does.  I published v=spf1 records before the attempted merger of SPF 
and MS Caller-ID for E-Mail.  I'm in a bit of a bind due to this decision.

My DNS provider only supports one TXT record per domain name, so the 
proposed PRA opt-out is not an option for me.  

I participate in a number of mail lists.  Some add a 2822-Sender.  Some 
don't.  Subscribers to mail lists that don't add the 2822-Sender whose 
providers check PRA will get a Fail for my e-mails.

As it stands, I've got no way to stop this other than abandon SPF too.  
That doesn't seem right.

>What to do? The appellant could withdraw his appeal and
>allow "sleeping dogs to lie where they are." 
>
>However, if the appellant persists, which seems likely,
>then given the historical background, the IESG should:
>
>* Withdraw approval for both the Lyon and Schlitt drafts;
>and 
>
>* Call upon the authors of the respective drafts to
>reconcile their differences at which time both drafts can
>proceed to be published as experimental drafts.

Please suggest a way this is possible that doesn't leave me forced to 
either suck up bogus PRA failures on mailing lists or abandon SPF.  

Despite suggestions by some, this is a technical issue, not a social issue. 
 If my e-mail getting delivered weren't at risk, I wouldn't be staying up 
late writing this.  Early in MARID I argued for record re-use, but during 
the discussions of the working group I became convinced it was a bad idea.  

>In turn, if a negotiated settlement can't be reached within
>a suitable time frame, the IESG could decide to call upon
>the authors of the Schlitt and Lyon drafts to re-file their
>documents as informational RFCs only, merely documenting
>matters for historical purposes, which the IESG could then
>approve for publication.

Given the extensive experimentation already concluded with SPF and the broad review given the 
Schlitt draft prior to submission, I think if both drafts are to be reconsidered, it would make 
more sense to publish the Schlitt draft as a standards track RFC and 
publish the Lyons draft (less the re-use of v=spf1 records) as an 
experiment built on top of it.

>This stance places a hammer over the heads of both sides to
>settle matters and if not, to bring the experiments to an
>end as being "ill starred" at least in the IESG's eyes.
>
Without practical time travel, I'm not sure what there is to settle.

Scott Kitterman



_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]