ietf-822
[Top] [All Lists]

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

2005-03-02 20:15:32

In <20053293512(_dot_)007816(_at_)bbfujip7> Dave Crocker 
<dhc(_at_)dcrocker(_dot_)net> 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 spf-discuss(_at_)v2(_dot_)listbox(_dot_)com 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