Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt

note:

For those of you who have avoided the MARID WG and email
authentication in general, both Dave and I have been very active in
this area.  Dave has a somewhat competing proposal called "CSV" and
has made it clear that there are various things that SPF does that he
doesn't like.  (Actually, off hand, I can't think of anything about SPF
that Dave does like, but...)


In <200532223445.613242@bbfujip7> Dave Crocker <[email protected]> writes:

>  On Wed, 02 Mar 2005 23:32:29 -0600, wayne wrote:
>>  I am really trying to aim toward your first goal.
>>
>>  SPF, as a protocol, isn't so entrenched that nothing can really be
>>  changed, but it is far too deployed to make any significant changes.
>
> I suspect you did not really understand Keith's point.
>
> You really do have to choose one of the two goals he listed.  "Trying" is not enough.

I'm sorry Dave, but I don't know everything.  Since I don't know how
every SPF implementation out there works, all I can do is try.  I do
know that various SPF implementations have had bugs that have been
fixed, and the percentage of deployed SPF implementations that still
have those bugs is decreasing.   I know of many different SPF
implementations and I know that several of the most popular ones
implement some things differently.

I do not think it would be appropriate to list every bug/difference in
every version of every SPF implementation.  Neither RFC822 nor RFC2822
do that either.

> As it is, I still have no idea what is in scope and what is out of
> scope for the effort.

Well, I'm not sure how to make it clearer.  Try asking your questions
and/or making your comments.  That will likely clear up the
miscommunication. 


> If you are trying to document what exists, then there is no 'still
> changing'.  None.

Sorry, but as I learn more about various things, my understanding of
what exists changes.  "Existing practices" are also changing, and will
continue to change.  Some of these changes are predictable, many
aren't.  I don't see this as a black and white area.  It is not
possible, and I don't think worthwhile, to document exactly what
things were like on a precise point of time.


Maybe we could use the example I gave in a previous message about the
Received-SPF header.  Should I document what was allowed under the
older SPF specs, which doesn't even match RFC2822's "obsolete" syntax,
or should I document something that is largely compatible with all
implementations that I know of and compatible with RFC2822?  I think
it reasonable to say that an already large percent of Received-SPF
headers conform to what is in the I-D (e.g. RFC2822 compatible), and
that in the future, this percentage will increase.



> If you are trying to document what you would like, I encourage you
> to either join the IETF process, by getting a working group
> chartered, or come back when you are done. It does not make sense to
> use part of the IETF process, except not really using it.

The IETF, in the form of the IESG, has made it clear that they do not
want SPF going through a working group.  That is part of why MARID was
shut down.  They are pushing through both this SPF I-D, and the
Microsoft Sender-ID I-Ds, apparently without even an IETF last call.
Maybe the MS folks made the right choice by not letting the other
relevant WG know about their I-Ds and I should have just kept quiet.

The IETF seems to be a pretty funny organization.  They clearly value
politics over technical considerations.   I'm not sure that I want to
go through the effort of trying to create a working group, knowing
that I don't have the political clout to keep things focused on
technical issues.


-wayne