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

[Scott Kitterman]

...... Original Message .......

"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]
* 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,
* 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

[Scott Kitterman]

...... Original Message .......

"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]
* 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,
* 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

[John Glube]

|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