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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 26 Aug 2005 12:44:03 -0700

> Behalf Of wayne
> > At some point there is a boundary between infrastructure the sender 
> > has control of and where he does not. That boundary is very clearly 
> > defined in my universe but even if it was ambiguous it would still 
> > exist.
> 
> The problem is that for different identities, this "boundary" 
> is different.  In particular, the boundaries between the SPF 
> identities (2821.MAILFROM and 2821.HELO) are different than 
> SenderID (PRA).

The identities are completely irrelevant.

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.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 26 Aug 2005 22:31:54 +0200

Hallam-Baker, Phillip wrote:

> Once that boundary is defined the definition is fair game for
> any party to use to interpret it to meet their operational
> needs.

The boundaries are different and incompatible for spf2.0/mfrom
(roughly te same as v=spf1) and spf2.0/pra.  That's the point
of the appeal, replace one occurence of "pra,mfrom" by "mfrom"
in chapter 3.4 "backwards compatibility".

Have you ever seen an RfC claiming that you can interpret MD5
as truncated SHA because after all they are both only hashes ?

                         Bye, Frank

---

From: "John Glube" <[email-masked]>
Date: Fri, 26 Aug 2005 23:15:32 -0400

|-----Original Message-----
|From: [email-masked]
[mailto:[email-masked]] On Behalf Of
Hallam-Baker, Phillip
|Sent: August 26, 2005 3:44 PM
|To: wayne; [email-masked]
|Cc: [email-masked]; [email-masked]
|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.

---

From: "william(at)elan.net" <[email-masked]>
Date: Sat, 27 Aug 2005 12:00:30 -0700 (PDT)

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

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

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

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

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.

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

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

> response America Online announced its continued support for

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.

> its place the Schlitt draft.

See above, I think I explained more how this all really came about.

> which flowed out of MARID, was now relying on the Schlitt

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.

> which conflicts with the backward compatibility arrangement

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

> experiments, with very strong disclaimers.

Yes, mistake on their part.

> allow publication of the Lyon draft based on the conflict

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]

> * Withdraw approval for both the Lyon and Schlitt drafts;

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.

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

> matters for historical purposes, which the IESG could then

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]

> arrangements with America Online and Microsoft, I was in

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.

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

> 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
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Sat, 27 Aug 2005 17:35:18 -0700

>       SPF2.0 record would be needed.

This overlooks a problem related to abuse-feedback techniques accruing
to "Sender-ID verified" identities.  An erroneous positive verification
based upon a PRA, unchecked by the sender perhaps due to licensing
issues, could be a serious concern.  These SPF records are public and
outbound servers are often shared.  

Neither of the path registration schemes provide domain protection at
shared servers.  Even with MTA checks to mitigate domain spoofing at
shared servers, these checks may also be limited by the same licensing
issues.

This retains a need to understand the assurances made by the sender with
respect to the scope of the record, and is unrelated to how a failure is
handled.  Assume the miscreants will know what passes.  

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 28 Aug 2005 04:58:43 +0200

william(at)elan.net wrote:

> SPF aims at stopping spoofing of RFC2821 MAILFROM address
> and to prevent backcuster of delivery failure messages when
> address is misused.

Yes.  (I've reduced the X-posts to mxcomp - maybe a bad idea)

> 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

Good point, unreliable results are also bad for PRA checks.

> 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

IBTD, they are listed as "inventors" in the patent application
<http://tinyurl.com/6lczr>.  I doubt that this happened against
their will - okay, with all this "opt-out" madness everything
is possible, but for a patent the lawyers would try to avoid
all formal problems.

> 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

The consensus to separate SPF from PRA, or rather MAIL FROM
from PRA putting aside HELO for later, was IMHO very clear.

When Mark was asked to create marid-mfrom-00 (and did within
less than a week) I really thought that the WG would finally
start to do something productive instead of XML-over-DNS,
dubious 2822-PRA constructs, and IPR issues.

But three days later it was closed.  The first process failure
in this saga, or rather the second, discussing CID / SID at all
instead of the clean LMAP proposals was already desastrous:

The ASRG is essentially dead since Yakov resigned, one day
after CID was pushed on the LMAP stack as surprise-MARID-input.
 
> 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

Meng published "an apology for Sender-ID" as I-D, at this time
he knew well that "unified SPF" did not represent the wishes
of the community,  He proposed v=marid as clean way to solve
the "Olson objection".  Not sure about others, but I accepted
the latter.  I never had a problem with the idea that those
who _explicitly_ want it should get PRA, it's their mail.

> It would be nice to know what happened behind the scenes.

At least the MARID Jabber logs are public, the last two are:
<http://www.xmpp.org/ietf-logs/[email-masked]/2004-08-04>
<http://www.xmpp.org/ietf-logs/[email-masked]/2004-09-20>

> what you see here is an example of why IETF standardization
> work should be done in public instead of private.

Tricky to get the WG Charter right.   I'm still surprised that
LTRU actually produced something, in that case it worked well.

For DKIM I'm less confident.  Maybe if Dave adopts some ideas
from among others Doug and Earl - that false promises and hype
are a trap should be clear after SPF, "we" cleaned the field
by testing most errors. ;-)

> they really do need to be viewed as separate individual
> submissions and should be judged on their own merits.

True.  But there's nothing wrong with spf2.0 reusing the ABNF,
protocol, error handling, processing limits, SPF RR, etc. of
v=spf1.  If they're lazy enough they can even reuse the rather
obscure Received-SPF, unlike Authentication-Results that's at
least in a shape which _might_ survive Bruce's^Wan IETF review.

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

ACK, mainly it adopted revolutionary ideas like "ABNF must pass
Bill's parser" and all the other formal nits... <eg>  Okay, it
also reduced Doug's imaginary "thousands of DNS queries" to now
only "hundreds".  Or in other words roughly ten for the worst
non-attack case.

 [senderid]
> 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.

Indeed.  

> please understand that v=spf1 document does not represent
> MARID work perse

Of course not.  After MARID was closed Mark proposed to resume
the work on v=spf1, the community decided to follow this plan.

> slightly further developed and better documented (with that
> documenting being in part result of working at MARID).

The RfC is _much_ better than the last pre-MARID draft.
 
> I believe at this point the appeal is only to IETF chair and

Pardon ?  AFAIK there are only four appeal levels, to the AD
in the case of a WG, to IETF Chair in the case of the IESG, to
the IAB in the case of a process failure, and finally ISOC.

> now only one person from IESG has opportunity to overrule
> them.

Are you sure ?  Where can Brian overrule the IESG ?  He's only
the primus inter pares, the AD of the general area.  Like our
SPF Council Chair.

> The appeal is only against SID draft

It's only against four letters in this draft from my POV.

> SPF draft should continue to be viewed as separate submission
> and decided on its own merit.

Of course, as you see in the tracker that's precisely how it
was handled.

> As far as MARID work IESG wanted, the correct thing is start
> working on SPF2/3 where we left off at MARID

If the IESG would have "wanted" any further MARID work they'd
not have closed this WG, don't you think ?  IMHO they want as
less as possible to do with MARID.  Even in the course of my
aborted MARID appeal it was clear (from my POV) that reviving
MARID after its sudden death was and is no option.

SPF is a free and open project, we now have our own elected
Council.  I'm not interested to exchange it against the IESG.
We tested this approach here in MARID, it failed, forget it.

If XMPP can do it, SPF can also do it, and if it doesn't work
we're at least sure that it's our own fault, and not some big
player pulling strings in backchambers.

> SPF community agrees to soften v=spf1 draft and allow for
> use of positive results with other identities

Over my cold and dead body, pseudo-PRA-PASS phishing is ugly.

We can offer op=pra opt-in, time to publish this as I-D when
needed about 60 seconds.  For "we" read SPF-TINW, not IETF-we.

                          Bye, Frank

---

From: "william(at)elan.net" <[email-masked]>
Date: Sat, 27 Aug 2005 22:04:52 -0700 (PDT)

> outbound servers are often shared.

I did not say its good way for the future, but it does eliminate the cases 
of failures [i.e. email not delivered] due to record being used by incorrect
protocol, which  is a lot worse then what you describe. And what I said 
is that this maybe an acceptable [temporary] compromise (not something that
either side is fully happy with) while waiting for permanent solution, which
is #3 on on my list -.both sides agree to work on the next version of SPF 
that has clear scoping and when finished promote that instead of spf1.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "John Glube" <[email-masked]>
Date: Sun, 28 Aug 2005 11:12:39 -0400

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

With respect, this does not correctly state what I mean, which
is partially my fault as I should have written:

|The underlying benefit of e-mail authentication for senders
|interested in e-mail delivery is to establish a framework that
|supports certification and reputation services, both external
|and internal to facilitate the delivery of ham, while rejecting
|spam [1]

I fully understand that the design objective of SPF (Mail
From authentication) is to help thwart domain spoofing and
that of Sender ID (PRA authentication) is to help prevent
domain phishing. 

My point is that saying to commercial entities involved in
the sending of solicited bulk e-mail, transactional and
relationship e-mail that receivers can use their sender
policy records for what ever purpose they want,
irrespective of the stipulated protocols is not acceptable.

As to the rest of the discussion, it seems SPF folks
supporting the appeal are not interested in pushing back on
Microsoft as it relates to the IPR and License, but simply
want to fully sever the relationship between spfv1 and
spf2.0.

In that case, I presume the SPF Community has no problem
with these potential developments:

* The IESG, based on the Chair's recommendation, deciding
to revoke publication of the SPF Classic and Sender ID
drafts as Experimental RFC's.

* The IESG asking Messrs Lentczner, Wong, Katz and Lyon to
produce a set of drafts for spf2.0 as experimental RFCs
based on the work done during MARID, with Messrs Lentczner
and Wong doing the work on spf2.0, mfrom and Katz and Lyon
doing the work on spf2.0, pra.

* The IESG asking Messrs Schlitt and Wong to resubmit the
spf-classic draft as an individual submission outside of
MARID for consideration as an informational RFC.

* Hotmail/MSN and various vendors of filtering software
that presently use spfv1 records telling senders they need
to publish spf2.0 records.

* Hotmail/MSN dropping all public support for spfv1,
including amending its web sites and wizard accordingly.

* SpamAssassin, to remain competitive, announcing its
support for spf2.0, mfrom in the next version of its
product.

* AOL, having been spurned by the SPF Community, deciding
to join Hotmail/MSN and support the full transition to
spf2.0.

Will these developments happen? I don't know. But,
hopefully folks have gone into this with their eyes wide
open. Given the reaction of some to the initial comments
posted by members of the IESG, I fear this is not the case.

As such, there is every possibility that those supporting
"technical purity" within the SPF Community are in for a
rude awakening, with the end result being further Internet
balkanization.

John Glube

---

From: wayne <[email-masked]>
Date: Sun, 28 Aug 2005 23:49:59 -0500

> in arms over the IPR disclosure by Microsoft.

That was not the only objection to SenderID and the PRA.

The objections to SenderID and the PRA include:

* The re-purposing of the Resent-* headers.  The SenderID drafts
  require forwarded email to add Resent-* headers, while RFC2822
  explicitly says that forwarders are not supposed to add these
  headers.

  Since forwarders do not currently add Resent-* headers, it would
  have been just as easy to create a new header for this purpose.

* The PRA can not distinguish between these two cases:

  1) An email is sent to a mailing list, which adds a Sender: header,
     and then the mailing lists sends it on to an email forwarder.
     According to the SenderID documents, the forwarder needs to add
     the Resent-* headers.

     The resulting email will end up with both Sender: and Resent-*
     headers.

  2) Someone "bounces" an email (in the pine/elm/gnus sense of
     re-sending the email) to a mailing list.  As per RFC2822, these
     MUAs correctly add the Resent-* headers to the email.  The
     mailing list then adds a Sender: header.

     The resulting email will end up with both Sender: and Resent-*
     headers.

  The PRA has to give incorrect results in at least one of these cases.

* The re-purposing of the SPFv1 record, as outlined in this appeal.

* The PRA has a higher error rate than SPF since it fails not only in
  cases where there is forwarding going on, but also on many mailing
  lists. 

* SenderID and the PRA is no more effective at stopping phishing than
  classic SPF.  

  Simply displaying the "PRA PASS" result actually makes the phishing
  problem worse, unless you also display the domain name that caused
  the PASS result.  Otherwise, phishers will put a [email-masked]
  on the From: header, and add a "Resent-Sender: [email-masked]", and
  the result will be a PRA PASS which looks like it came from paypal.

  If you display the domain that caused the PRA PASS, you can just as
  easily display the domain from the Return-Path and use SPF instead.
  At this point, there are no advantages to using the PRA.

Of course, there was also:

* The PRA requires a patent license that is incompatible with several
  open source licenses, representing a significant number of MTA and
  spam-filter software currently deployed.  It also requires
  commercial companies to inform Microsoft when they plan to create a
  product that uses the PRA.

And finally, there are people who objected to both SPF and SenderID
because:

* Both SPF and SenderID break forwarding.

* Both SPF and SenderID require everyone to either send email through
  designated MTAs, or to have special exceptions created often
  requiring specialized software.  This is known as the "working from
  home user", "roaming user" or "traveling salesman" problem.

* Both SPF and SenderID break greating-card sites and the "send a news
  article to a friend" sites.

The licensing issue was most certainly *NOT* the only cause for the
closing of the MARID WG.

All in all, the PRA has lots of disadvantages compared with SPF and no
advantages.  (Other than support by MS, that is.)

Except for the cases of the re-purposing of SPFv1 records and the
re-purposing of the Resent-* headers, I think the market can deal with
the problems with the PRA.  

> authentication with spfv1 records. [2]

You can't "negotiate" over technical problems.  No one can create
"backward compatibility" by decree. 

> * Both drafts flowed from MARID. 

You have the timeline slightly messed up here.  The work Mark
Lentczner did during MARID was not about SPFv1, it was about SenderID.

Mark created an SPF-classic draft *after* MARID was shut down.  There
is some dispute about whether this was intended to be part of the call
for individual submissions made when MARID ended, but it was never
intended to be used as the basis for the SenderID drafts.

The fact that the lentczner-spf-00 I-D did not include support for the
HELO identity was one of many incompatibilities with earlier SPF
specifications and deployed SPF implementations.  It was due to the
large number of incompatibilities that the lentczner-spf-00 draft never
reached a rough consensus level of support within the SPF community.

> used for both mail from and PRA authentication.

It should be noted that the SPF wizard that Microsoft created produced
completely invalid SPF records until shortly before the FTC Email Auth
Summit, which was long after MARID closed.  The number of records with
these tell-tail errors is actually fairly small, indicating just how
little MS backing for publishing SPF records actually had.  

-wayne