In <427941AD(_dot_)9040306(_at_)ohmi(_dot_)org> Radu Hociung
<radu(_dot_)spf(_at_)ohmi(_dot_)org> writes:
But there has been some good discussion in the past months. It needs to
be reviewed before you can hope to get more comments of the -04 or -05
drafts, as many comments were aimed at the previous draft, and you have
not addressed them yet.
As I mentioned earlier, I *have* read many of the posts in the last
several months and skimmed many more, and in the past week or so, I've
made an effort to catch up. Things like the SPF website, roadrunner's
SPF records (before it evolved into the DNS load stuff), the email
forwarder's protocol, etc. all do not involve the draft.
The DNS load issues do, but from what I could tell, it was a rehash of
older discussions, and I haven't seen a compelling reason to change
the draft due to those discussions. I could easily be missing
something though.
At this point in time, I think it might be best to post a new message
with anything important that you think I've missed. For example, your
"DNS load summary" post[1] makes a good start, but it is all
assertions, without references to back them up (e.g. links to posts
for each person who took a position on each of those assertions, or
something).
My general opinion on the number of DNS lookups allowed in the spec is
that the current 111 maximum is low enough to make the DoS attack
scenarios less effective than other DoS attack methods, it is easy for
people to add up in their head, and it has been implemented by at
least one SPF implementation for a long period of time.
In order to justify changing the spec, I would want to see a better
analysis of why the limit MUST be lowered, and/or why another method
of counting in much easier, and/or which SPF implementation(s) have
implemented the alternative DNS counting limit.
[1]
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200503/0329.html
SPF is currently a small scale experiment, a learning experience if you
will. To say that its current state is worthy of standard status is a
little much for me to grasp. That would literally mean that we haven't
learnt anything, that we haven't found anything that needs to be corrected.
I strongly disagree that SPF is currently a small scale experiment. I
believe that SPF passed out of the "experiment" stage back in late 2003
or early 2004.
I really believe that it SPF is as good now as it will ever get, it has
been a waste of time.
I'm sorry to hear that.
Do you really think that SPF in its current incantation can stand the
test of 20 or 30 years?
Maybe, maybe not. I do, however, believe that significant changes
should be put into a future RFC, not the current one.
Also, the fact that you suggest lookups on an SPF RR, when one is not
defined, will also not go well, I believe.
The SPF RR is requested to be allocated in the IANA consideration
section. During the IESG review, the IANA said that they could do
it. During many different discussions with various DNS folks, the
creation of a new SPF RR is not only strongly supported, but I suspect
that a great many of them would like to see all references to TXT RRs
deleted.
Until the new RR is documented, it is only imaginary.
It takes a lot of effort to document and implement a new RR world wide,
and to formulate a transition plan. By comparison, the effort to make it
binary instead of text is miniscule incremental effort.
By the way, have you considered the transition plan?
I have, and I did not conclude it will be easy.
I have stated many times that I believe that the new SPF DNS RR is
completely useless, it will never be used in any significant way, and
there can be no effective transitional path. In this opinion, I
believe I'm in complete agreement with the microsoft folks (Harry/Jim).
However, there are many people who disagree with me and in my role as
the current editor, I think it is best to put it in. My willingness
to battle this issue is limited to giving TXT RRs more equal time with
SPF RRs compared with MarkL's draft, something that I've received a
number of complaints about.
Personally, I think it is flawed to assume that an eventual SPF RR will
take a form as inneficient for SPF purposes as text strings. A binary
format closer to your "byte compiled" syntax in libspf2 is more likely.
I had hoped that a binary format would gain support, but it never
really did. By far the strongest support is for the SPF RR to be
a clone of the TXT RR.
Support will come once a well-thought proposal comes along.
I suspect not, but by all means, go for it.
-wayne