In <20053293512(_dot_)007816(_at_)bbfujip7> Dave Crocker
There is a new I-D for the SPF email anti-forgery system available for
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"?
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
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.