In <004901c5692a$43601380$6c62fea9(_at_)ibmrkydk2ufvdd> "John Glube"
<jbglube(_at_)sympatico(_dot_)ca> writes:
And please remember that Carl Hutzler, in his posts to
ietf-mxcomp went on to write, in essence, if you want to
use it (referencing v=spf1 and speaking of SMTP mail from)
for anything else, it is your network and your rules, but
...
This much I agree with
(I am paraphrasing.)
So, let's accept the limits of v=spf1 given the general
state of affairs, let the folks who are pushing network
security, push network security, acknowledge the edge cases
and tell network administrators what is the highest and
best use.
If you want to apply for a standard for v=spf1, see the
IESG reject the request and then proceed to set up your own
standards body, hey that's your choice. But, that is a road
I can't follow.
I'm not sure how much of the above you are parapharsing Carl, but I
disagree that he said such stuff.
We need to remember what the IESG said when closing down
MARID:
<snip>
|Rather than spin in place, the working group chairs and
|Area Advisor believe that the best way forward is
|experimentation with multiple proposals and a subsequent
|review of deployment experience. The working group chairs
|and Area Advisor intend to ask that the editors of existing
|working group drafts put forward their documents as
|non-working group submissions for Experimental RFC status.
|[wrs's snip]
<snip>
That was and is the whole purpose of the IESG process from
the perspective of the SPF community. To have a focused
technical review of the protocol for v=spf1, before
proceeding with publication of an authorized IETF
experimental document to allow for wide spread
implementation.
From the perspective thof this SPF community member, the "IESG review
process" was pathetic. The DEA directorate that they set up and the
IESG members gave almost zero feedback about any problems with the SPF
I-D. Almost all of the comments, suggestions and corrections that I
have received are a result of me directly soliciting comments from
here and on the various IETF mailing lists.
I think I received one (1) email from a DEA member, which asked, in
part, why this wasn't being done as a Standard Track RFC. The only
IESG suggestions that weren't triggered by my own call for reviews was
that the version number should be in the title, and the removal of the
"other identity checking is NOT RECOMMENDED" sentence.
We did not need the IETF to allow for wide spread implmentation of SPF
in the past, and even if the IETF rejects it now, I don't see that it
would slow down SPF that much. (Yes, IETF approval would speed things
up, which would be good.)
Keep in mind the purpose of an experimental protocol:
|The "Experimental" designation typically denotes a
|specification that is part of some research or development
|effort.
Right, which doesn't describe the SPFv1 protocol that has been in use
and largely unchanged since late 2003/early 2004.
I appreciate that while the IESG process has been ongoing,
field testing of various proposals has continued.
There appears to be some field testing of DK, but I haven't seen any
indication that there are test going on with the MARID protocols.
The benefit? The Community is getting a fairly good idea of
the strengths and weaknesses of v=spf1 as part of the
ongoing effort to come up with a scheme for email
authentication that works.
Even if we do come up with something new to address the problems with
SPFv1, I don't see the deployment of SPFv1 ending any time in the near
future.
-wayne