Re: Re: Draft IETF appeal

See the end of this post for new info for the appeal.

On 8/24/05 8:16 AM, wayne sent forth electrons to convey:
> Neither SPF nor SenderID protect the From: header.
On 8/23/05 3:54 PM, Julian Mehnle sent forth electrons to convey:
> ...What's even more important is that we all watch the "technical 
> community"
> lists (at least IETF <ietf(_at_)ietf(_dot_)org> and MARID <ietf-mxcomp(_at_)imc(_dot_)org>) for 
> discussion of the appeal over the next few weeks, and are prepared to 
> refute any bogus arguments that are brought up.  We should expect Doug 
> Otis and other SPF haters or Sender-ID lovers to try to rip the appeal to 
> shreds.
I doubt it.  I for one support the appeal.  Sender-ID is in conflict 
with SPF3 as well as SPF and SPF Classic.
Whatever SPF's flaws, the fact is, Sender-ID is technically plain wrong, 
as the appeal explains.
Approving a conflicting spec was a technical error on the part of the 
IESG that needs to be corrected.  (RFC 2418 indicates that the IESG must 
have assigned the Sender-ID I-Ds the status 'Experimental'.)
The technically more correct thing to do (if one wanted to redefine 
spf1) would be to put out an I-D that attempts to obsolete SPF, but that 
hasn't happened because SenderID has little traction.  As my post 
yesterday showed, not even Microsoft has implemented SenderID.  Also, 
because of the significant deployment of spf1 records, there is no 
correct way to redefine the semantics of spf1 records. For these good 
reasons an I-D that attempted to obsolete SPF won't progress (assuming 
the IETF works as it's supposed to).
BTW, Wayne: apropos your question here:
http://www.circleid.com/article.php?id=1157_0_1_0_C/
as to what the difference between SPF and SPF3 is :
(You stated: "It isn't clear to me all of the differences between your 
draft and the marid-protocol draft is.")
The initial SPF3 announcement at
http://www.imc.org/ietf-mxcomp/mail-archive/msg04948.html
answers that question.  It says in part:
> Well, draft-ietf-marid-protocol-03.txt was very disappointing, [new 
> comment: Author statements had let me to expect that it would require 
> HELO checking.] so I went ahead and did what needed doing.
> I made some edits and made a new Internet-Draft based on it: SPF3.
> I summarize the changes as follows:
> s/typos/corrections/
> s/Most of 6.2 Processing Limits/<new text>
> s/mail from or PRA/HELO/
> s/mfrom,pra/helo/
> s/spf2.0/spf3.0/
> s/Mark,Meng/me/
> s/SenderID/SPF3/
> Some tweaks to the Abstract.
> Allow SPF1 records to be used. Strangely, 
> draft-ietf-marid-protocol-03.txt didn't allow this!
> The effort put into the edit may have produced something of lesser 
> quality than one expects from Microsoft.
> Comparison of SPF3 and CSV+MPR:
> Organizationally, it's superior, in that it leverages the existing 
> base of SPF1 records. It's easier to understand, includes examples, 
> and it's easier to create TXT records - of bind, GoDaddy and ZoneEdit, 
> only BIND supports what CSV requires. Technically, it's inferior, in 
> that its usage of DNS is less efficient and less standards-based. MPR 
> also has the cool bitmapped fields for explicit protection of 
> 2822.From:, etc. This could be added to SPF3.
> Comparison of SPF3 and SPF1 or SenderID:
> It's superior, in that it doesn't break forwarding, is much more 
> efficient, and can't be tricked by forged or misleading headers, 
> requires about 99% less effort to implement, on a global basis, is 
> based on an algorithm that predates M$' patent filing, and provides 
> something that can be better accredited.
> ...
>
> There's a false statement in Microsoft's previous IPR disclosure 
> statement:
>     VIII. Other Notes: ** A license to implement these specifications
>     will be made available at http://www.microsoft.com/mscorp/standards on
>     or before September 15, 2004.
Note that the above issue appears not to have been corrected. It 
violates IETF policy and defrauds the IETF and hence is another reason 
for the draft needs to go.  Immediately.