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

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

>>  There is a new I-D for the SPF email anti-forgery system available for
>>  review.  ...
>>  Discussions about this, and previous, drafts have been taking place on
>>  the [email protected] mailing list.  ...
>>  for the purposes of this
>>  draft, I am very reluctant to try debate these issues.  The goal is to
>>  document a de-facto standard.  Debates about better techniques, why
>>  SPF is evil, etc. are probably best discussed on things like the IRTF
>
> so the constraint to review feedback is either "yes it works this
> way" or "no, it doesn't, it work's this other way"?

Not entirely.

While I'm very interested in learning about things that SPF
implementations usually do that aren't (adequately) document, or
things that are documented that most SPF implementations don't do,
there are still a few things that are being changed around the edges.
Basically, the more incompatible the suggested change, the more
evidence will be required that it is a *really* important and
necessary change.

What I really wanted to head off with what I said above are comments
like "we should use SMTP callbacks instead!", or "instead of an ad-hoc
language, we should use XML", or "we shouldn't use DNS to communicate
the sender policy", or "SPF's HELO checking could be done with one DNS
lookup instead of the current one or two if we used an A RR type.".
All of these positions have been strongly argued both pro and con.
The point is that any of these changes would result in something that
*isn't* the existing SPF and therefore *isn't* the goal of this I-D.

Most of all, I wanted to avoid re-hashing these issues here.


-wayne