Post by John Glube|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]
With such a statement you're making an assumption that the technology
(i.e. SPF and SID) is only good for sender authentication and anti-spam.
This is a common mistake, especially in regards to SPF, and is largely
due to how the technology has been marketed by many. But it is all not
technically correct as SPF aims at stopping spoofing of RFC2821 MAILFROM
address and to prevent backcuster of delivery failure messages when
address is misused.
Also what is true about SPF may not be true about SID and as they operate
on different identities you're bound to see problems if incorrect record
is used.
Post by John GlubeA sender publishes a policy record based on a protocol in
anticipation that recipient networks will use that record
in accordance with that protocol.
Correct. And with two conflicting specifications it is difficult to
understand what the intent of the sender is. This is a problem for
both SID and SPF protocols and unless resolved it discourages
participation of users in these experiments and thus IETF would
be enable to get true results about usability of the technology.
[skip]
Post by John Glube"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.
The IPR disclosure's problem was not actually IPR limited text itself,
the main problem was how it happened and that many (I'll go as far as
to say majority of individual participants at MARID) lost trust in
Microsoft especially after the disclosure of their overreaching patent
applications. It is really failure of Microsoft to be able to play
fair and work together with open-source and similar communities even when
both sides were willing to try for common good (and the technical people
from Microsoft participating at MARID were not at all responsible for it,
they were victims of the decisions made quite deep at their company).
Further work of the WG would have been very difficult with two sides not
being able to easily talk to each other (which would make it difficult to
come to consensus, although if given time to cool down it could have been
possible, but you can see this difficulty even now with SPF and SID drafts).
Post by John GlubeAt 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.
I don't think it was the reason. They knew about luck of backwards
compatibility even before and did not say anything. I'll go as far
as to say that somebody asked AOL to temporary withdraw support and
they were willing to play along.
Post by John GlubeMr. 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 problem is that Meng never understood about real causes for failure
of MARID as I tried to describe above and did not understand concerns of
those who actually created SPF (he was editor of the original draft and
"managed" the group but not really author of the technology which came
together based on work of individual participants at spf-discuss), he
assumed himself to be appropriate representative of open-source-like
group that created SPF and that he could on their behalf continue to
talk and work further with MS to create common standard as MS wanted
from MARID, but in the way he did it, he just showed further where
MARID was failing and why it was appropriate for work to now be done
on two *separate* "experiments" as IETF asked.
The result is that there was a lot of outrage at the spf-discuss in
October/November 2004 when new individual submission SID draft came
out with reuse of v=spf1 records and consequently Meng was removed
from being person responsible for representing views of SPF and
replaced with group of people (SPF Council), plus primary editor
of the SPF documents was also replaced. This was not unexpected if
one could understand what happened at MARID.
Post by John Glube* 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.
Partially true (drafts did "flow" from MARID, but there were already
significant differences then the actual MARID drafts).
And as far as Mark Lentczner's spf draft it was already partly in the
way SPF community wanted as far as documenting real v=spf1, but he was
just not willing to take it further (probably also did not understand
what happened at MARID and wanted to continue that work largely as is,
plus he probably knew about agreements Meng was at the same time making
behind the scenes with MS and AOL).
Post by John Glube* The Lyon draft supported backward compatibility and in
response America Online announced its continued support for
Sender ID.
It would be nice to know what happened behind the scenes. In fact it
what you see here is an example of why IETF standardization work should
be done in public instead of private.
Post by John Glube* 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.
See above, I think I explained more how this all really came about.
Post by John GlubeThe IESG was now faced with a situation where the Lyon
draft, which had relied upon the Lentczner draft, both of
which flowed out of MARID, was now relying on the Schlitt
draft for its underpinning.
Yes. And it is all result of that unfortunate attempt to "continue
MARID" with spf1 taken by Meng instead of proceeding as me and several
others originally expected as far as having v=spf1 documented first and
then quickly move to SPF2 as separate document series based on MARID and
proceeding further to UnifiedSPF (i.e. one common format for policy
records with separate identities/scopes and how to interpret those
identity records). That second document series would have been real
successor to MARID but it did not happen.
What you have now is that neither of the documents approved by IESG is
really MARID documents and they really do need to be viewed as separate
individual submissions and should be judged on their own merits.
SPF draft is best attempt so far to document SPF protocol as it was
developed prior to MARID (with only few things borrowed from MARID)
draft-lyon-senderid and other SID documents should be viewed as separate
private submission of proprietary Microsoft CID implementation which
instead of original CID XML DNS record has now adapted SPF record syntax.
And as separate submission made to IETF, it should also be responsibility
of IESG that their proposal does not come into conflict with other LMAP
proposed experiments and does not break any other IETF standards.
Post by John GlubeIn 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]
Again, please understand that v=spf1 document does not represent MARID
work perse - its separate submission documenting pre-MARID protocol
slightly further developed and better documented (with that documenting
being in part result of working at MARID).
Post by John GlubeSince neither side was prepared to budge, the IESG
ultimately allowed both drafts to proceed forward as
experiments, with very strong disclaimers.
Yes, mistake on their part.
Post by John GlubeNow 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.
I believe at this point the appeal is only to IETF chair and not to IESG.
[An interesting situation BTW - because IESG as a whole made decision to
proceed with drafts publication where as now only one person from IESG
has opportunity to overrule them. For government-like structure this
appears to show where IETF Chair has power of veto like President has
over decisions of Congress, but President represents separate branch
of government, where as in countries with parliamentary democracies
the prime-minister typically can not overrule the parliament]
Post by John GlubeWhat 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
That would not be appropriate. The appeal is only against SID draft
(should have been against all 3 SID drafts actually - they can't
be published separately). SPF draft should continue to be viewed
as separate submission and decided on its own merit.
So should (as individual submission on its own merit) be viewed
whatever MS comes up with and certainly there should be no conflicts
that arise from its when they want to reuse somebody else's record
or fields - it should be done only in a way that effects are limited
to those who agree to participate in their experiment.
Post by John Glube* 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.
You can "call upon the authors" once again but it has been done
before and it has not resulted in reconciliation so far. The
conflict that became clear at the end of MARID is still there
and so is inappropriate use of somebody else's work that MS is
so famous for.
Post by John GlubeIn 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.
Even for informational purposes publishing conflicting specifications
is not appropriate. There really is not much of a choice here - if
IETF/IESG agrees there is a conflict, it must request one of the drafts
to be withdrawn and fixed (and if author does not do it, IESG would have
no choice but to block it from going further). Since its the SID draft
that depends on SPF draft, the SID would have to be the one to be
withdrawn (i.e. SID can't be published without SPF draft where as SPF
draft can be published without SID). In separate post I'll show why its
correct to withdraw SID draft for other reasons too.
As far as MARID work IESG wanted, the correct thing is start working on
SPF2/3 where we left off at MARID and create it as new series where all
scopes are clearly separated. But what IESG really wanted was to
experiment with these technologies (I doubt they cared as to particulars
of the record syntax) and in fact SPF1 does in as far as providing
way to see how RFC2821 MAIL FROM verification can be achieved. For MS
the same could be achieved if they instead worked on further on original
Caller-ID (or it could be achieved if they published real MARID in the
way documents went to MARID at last-call in August with only spf2.0 used).
[skip]
Post by John Glube[2] At the time that Mr. Wong was negotiating the
arrangements with America Online and Microsoft, I was in
strong opposition.
Most others as well and he did not understand that it was just make
situation that brought end of MARID a lot worse which is exactly
what happened.
Post by John GlubeIn 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.
I suspect we both know some of the things that were not made
public and so I'll just note that happen to disagree. I do not
believe Microsoft would have been able to do anything more - it
really was not something that was up to the people who we were
working with, they've done all they could on this matter and in
fact said as much.
Post by John GlubeThe present situation, given the appeal to the IESG,
potentially creates the same opportunity, if one believes
there is merit in saving this particular experiment.
I do not believe it can happen now either and I think trying to
negotiate would hit the same road-block as before and it would not
be anything people seen as standing behind SID at MS (and thus
involved in such negotiations) could do anything about.
But if reuse of spf1 records is really realy the only way for MS
and it wants to continue, then the only possibility for negotiation
I see is to get it part the way for both sides. This would involve:
1. MS agrees to change its draft and only use positive results of
SID verification on v=spf1 records (but not fail, softfail or
results if record is absent) and that for negative results real
SPF2.0 record would be needed.
2. SPF community agrees to soften v=spf1 draft and allow for use
of positive results with other identities (I brought this up before
and while some thought it was ok, others thought there are is too
much potential for confusion and incorrect results even then - no
way can we come to consensus unless its really part of negotiation
and MS gives something else to make it worth it).
3. Both sides agree to work further on the next version of protocol
that would have clear separation of scopes and core protocol
document that both sides could then reuse [this would be real
successor to MARID]. Both sides agree that once such new documents
are ready, they will begin to promote this new version.
---
William Leibzon
Elan Networks
***@elan.net