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.
That's fine... however, if your spec if incompatible with other RFCs,
especially mainstream RFCs such the 2821, I think it will be hard to get
it passed as an RFC.
I do not believe that this SPF spec is incompatible with other RFCs,
or at least not seriously enough to prevent it from becoming an RFC.
This conclusion is based off of what various authors of RFC2822 and
RFC2821 have said during the MARID WG and also based on the recent
review by the IESG.
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.
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.
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.
Whether my RFC will pass or some other RFC will pass instead is
irrelevant. In your draft, you assume (I think) that SPF RRs will be
made of text strings, and that is unwise.
Despite my own personal bias toward using a binary SPF RR, I think
that using a text SPF RR is quite acceptable. It's a battle I fought
for and lost, and now I'm trying to write a spec based on the
consensus opinions, not my own.
-wayne