Re: HELO versus MAILFROM results

wayne wrote:

In <4278E84E(_dot_)80302(_at_)ohmi(_dot_)org> Radu Hociung 
<radu(_dot_)spf(_at_)ohmi(_dot_)org> writes:

wayne wrote:

You have listed many of the same anti-HELO-checking arguments that
have been listed before.  I will not repeat the pro-HELO-checking
arguments as they are found in the spf-discuss archive.



In hind sight, what I said here could easily be interpreted as Proof
by Authoratative Assertion, or simply blowing off the argument.  This
is not the case.  Recent history has show that I've had a very hard
time finding enough time to work on the SPF spec, let alone contribute
to this mailing list.  I'm just trying to focus on my top priorities.


Well, SPF needs a lot more work yet. I can understand that it might not
be your top priority, and I have no quarrels with that. :)

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.

Perhaps an informational RFC would be a better goal in this case. The
purpose of those is to document how things are, not how things should
be. That would be more in line with your stated goal for the current SPF
draft.



I do not see why Information is better than Proposed Standard.
RFC2822, for example, was created as a way of documenting what the
(then) current state of SMTP was.


You mentioned that with the current draft you intend to inform of the
state of SPF, not try to improve it. There's no shortage of well-founded
concerns that went ignored, perhaps unnoticed?

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 really believe that it SPF is as good now as it will ever get, it has
been a waste of time.

Do you really think that SPF in its current incantation can stand the
test of 20 or 30 years?

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.

The main question is where do you start? At the master servers? At the
slave NS servers? Perhaps at the caching servers? Maybe at the resolver
libraries? Or in an unplaned, random fashion?

All I am saying, unless these issues have been considered, and
documented, you should make no assumptions on what the SPF RR will look
like.

In a way, if it is a duplicate of TXT, there's no point spending the
effort to create a new RR.

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.

Radu.

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper!  http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com

smime.p7s
Description: S/MIME Cryptographic Signature