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

From: Scott Kitterman <[email-masked]>
Date: Sat, 27 Aug 2005 1:45 -0400

...... Original Message .......
On Fri, 26 Aug 2005 23:15:32 -0400 "John Glube" <[email-masked]> 
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

---

From: "John Glube" <[email-masked]>
Date: Sat, 27 Aug 2005 22:43:52 -0400

|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.

One of my fundamental difficulties with the whole
discussion surrounding SPF/Sender ID is that proponents
continually rely on an "installed base" as justification
for refusing to change.

What happened prior to MARID was pre-IETF. The exercise was
an experiment. 

I can't speak for others, but when I published my record in
June 2004, at the time I understood the discussion to be
about mail from authentication and domain owners protecting
their domains against spoof attacks. 

I also understood that SPF was an experiment and
ultimately, I may have to change my record.

Today, given what I know about the plusses and minuses of
SPF as a result of significant and ongoing testing, I would
have to say the reasons being put forward to encourage
people to publish SPF records were at best wishful thinking.

So, from my perspective, although I appreciate and respect
the desire to support early adopters, when the whole issue
of spfv1 and spf2.0 was reviewed during MARID, my
understanding was that:

* The included scopes within the SIDF were going to be
MFROM and PRA; 

* It was decided to include both scopes in the SIDF
protocol; and,

* People would have to upgrade their existing records.

Was I happy with this last decision? Not particularly and
at the time, I quite frankly did not understand the need to
proceed in that fashion. 

But, given the ongoing "troubles" as the Irish would say, I
now believe those who advocated the need to move entirely
to spf2.0 were correct. It certainly seems logical from an
engineering perspective.

Of course, spfv1 advocates would suggest that those who
even dare suggest such an approach as a solution are ...
well the idea is simply unspeakable and by even putting it
forward, I have joined forces with the devil, or something
worse.

Since it seems evident from comments made to this list and
elsewhere, that representatives of the SPF community wish to
pursue the appeal and are not interested in negotiation, then
speaking for myself, I ask that:

* The IESG chair accept the appeal and based on the
concerns raised request the IESG to review the decision to
grant experimental status to what is commonly called
SPF-Classic and Sender ID group of documents. 

* The IESG rescind the grant of experimental status to the
SPF-Classic and Sender ID group of documents.

* The IESG request the original authors for SPF being
Messrs Wong, Lentczner, Katz and Lyon to re-submit drafts in
accord with and subject to the conditions laid out in the
request for individual submissions made after the MARID
closure for experimental status.

* As to the SPF-Classic draft, although this falls outside
the scope of the conditions laid out in the request for
individual submissions made after the MARID closure, since
the IESG previously considered the document, the IESG
invite the authors, Messrs Schlitt and Wong to resubmit
this draft as an individual submission for experimental RFC
status.

* The IESG then based on the concerns raised in the appeal
and such other concerns and circumstances as appropriate,
treat the various submissions and make those decisions
which it deems appropriate in the circumstances as to which
if any drafts should be approved for publication as
experimental or informational RFC status as appropriate.

All that being said, I wish the parties and particularly
the IESG chair all the best, as he endeavors to sort
through this thorny mess.

John Glube