[Top] [All Lists]

Re: Re: Draft IETF appeal

2005-08-25 12:32:31
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:
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
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/Most of 6.2 Processing Limits/<new text>
s/mail from or PRA/HELO/
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.

<Prev in Thread] Current Thread [Next in Thread>