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

|-----Original Message-----
|From: [email protected]
[mailto:owner-ietf-|[email protected]] On Behalf Of
Hallam-Baker, Phillip
|Sent: August 26, 2005 3:44 PM
|To: wayne; [email protected]
|Cc: [email protected]; [email protected]
|Subject: RE: Appeal: Publication of draft-lyon-senderid-core-01
|inconflictwith referenced draft-schlitt-spf-classic-02
|
|The only relevant boundary is between what the sender
|controls and what they do not. All that any sender,
|forwarder or any other mail injector can ever be expected
|to do is to define the boundaries of the systems they
|control.
|
|Once that boundary is defined the definition is fair game
|for any party to use to interpret it to meet their
|operational needs.

I have a real problem with this last position. 

The underlying thrust behind sender authentication is to
establish a framework for use by certification and
reputation services, both external and internal to
facilitate the delivery of ham, while rejecting spam. [1]

A sender publishes a policy record based on a protocol in
anticipation that recipient networks will use that record
in accordance with that protocol. 

If recipient networks are going to use the sender's policy
record for any purpose, whether in accord with the stated
protocol or otherwise, then senders are better of not
publishing a policy record.

Otherwise, senders run the risk that the record will be
misused and result in legitimate, requested and in some
cases necessary mail not being delivered.

As to the appeal, in my mind having reviewed both protocols
with great care, we need to ask, what is "the conflict?"

* Draft-schlitt-spf-classic-02 says in essence that we do
not recommend receivers use spfv1 records for any use other
than that set out in this protocol.

* Draft-lyon-senderid-core-01 says in essence that
receivers can use v=spf1 records for PRA authentication. It
further advises senders to check whether their v=spf1
records can be used for this purpose and if not to publish
the appropriate spf2.0 record.

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

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.

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

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. 

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]

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.

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.

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.

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.

John Glube
Toronto, Canada

[1] The Federal Trade Commission supports "e-mail
authentication" in the belief that this will make it
easier to track down the bad guys. This position is based
on the view that the technical community can develop a
protocol which will receive wide spread acceptance and so
necessitate its use if senders wish to have their mail
delivered.

In my view, the reality is that network security is the key
technical umbrella. This umbrella can provide cover for the
appropriate cultural framework, especially within the
marketing and user community. In turn, this cultural
backdrop can then support the appropriate legislative
framework, which in turn supports the necessary technical,
legal and cultural drive to bring "the various problems"
under control. The problem? The necessary cultural and
legislative framework is absent from the mix, so leaving
gaping holes in the technical umbrella.

In saying this I acknowledge a strong bias against the
existing legislative framework, which I believe makes any
real solution unlikely. But that is a different debate.

As to e-mail authentication, this only supports one part of
a potential technical solution of how to deal with e-mail
after it is sent.

What role can SPF and Sender ID realistically play in this
process? I simply reference the MAAWG white paper released
on July 8, 2005:  

<http://www.maawg.org/about/whitepapers/spf_sendID/>

[2] At the time that Mr. Wong was negotiating the
arrangements with America Online and Microsoft, I was in
strong opposition. 

In my view, if pressed, Microsoft would have been prepared
to amend its IPR and re-write its license to meet the
concerns raised during MARID, in exchange for access to the
existing base of spfv1 records through the concept of
backward compatibility, rather than allow Sender ID to die. 

The present situation, given the appeal to the IESG,
potentially creates the same opportunity, if one believes
there is merit in saving this particular experiment.
 
[3] In my view, the IESG should have rejected both the
Schlitt and Lyons drafts as experimental RFCs, because they
did not flow from MARID. 

The Schlitt draft documents an historical reality as
opposed to supporting an e-mail authentication experiment,
claiming that all the work which needs to be done has been
done. 

The Lyons draft puts forward the concept of backward
compatibility, while the work done during MARID indicated
that this was the wrong approach. 

As a result both drafts were arguably outside of the
stipulated process for filing experimental protocols as
called for when MARID closed. 

Having said this, I understand the political desire to
utilize the existing record base of spfv1 records to
support the experiment. 

However once the "arrangement" was rejected by the SPF
Community by withdrawing the Lentczner draft and filing the
Schlitt draft, the IESG response should have been to reject
both the Schlitt and Lyon drafts and require the parties to
work in accord with the stipulated process based on the
work done during MARID.