In <200505221721(_dot_)29489(_dot_)blilly(_at_)erols(_dot_)com> Bruce Lilly
<blilly(_at_)erols(_dot_)com> writes:
On Fri May 20 2005 16:15, wayne wrote:
Sorry for taking so long to follow up on this thread. I'm afraid I've
been busy with other things. As this thread has already discussed
many issues, I'm going to try and keep this short and pick out just a
few points.
If the intent is in fact to change the intended
status from Experimental (I-D tracker) to Standards Track (as stated
by the author in the predecessor of this message; see below), then
the IESG may wish to initiate a New Last Call of at least 4 weeks
duration in accordance with the procedures for an individual
submission for Standards Track status as outlined in RFC 2026 (BCP 9).
Yes, my intent is to change the status from Experimental to Standard
Track. The Expermental designation was decided by the AD in a process
that involved some misunderstandings.
I would welcome the Last Call review, just as I have gone out of my
way to ask for two reviews from several IETF mailing lists already.
Debates about better techniques, why
SPF is evil, etc. are probably best discussed on things like the IRTF
ASRG list, SPAM-L, the NANAE newsgroup, or on spf-discuss on a
separate thread/subject.
On the contrary, I believe [...]
I'll leave it up to whomever runs this mailing list to decide whether
the current thread is offtopic or excessive. I am just all too aware
that when the subject of SPF comes up, it often triggers discussions
of spam, DNS, MUA design, phishers, and many other things that may
well not be on-topic for this list.
At a bare minimum, if the intent of the draft is in fact to document the
described mechanism, it should clearly delineate and emphasize those
rather serious defects in said mechanism, defects which are only
partially and begrudgingly acknowledged in the draft,
I disagree that the trade offs and implications of deploying SPF is
only partially or begrudgingly acknowledge in the draft. I have
worked very hard to try and keep the draft as short as possible, do
many of these things are not given long rants, but they are there.
undermined by language such as "It is RECOMMENDED that domains publish
SPF records".
No where in the I-D does it say that "It is RECOMMENDED that domains publish
SPF records". I strongly believe that it is up to domain owners to
choose whether to publish SPF records or not, and it is up to mail
admins to decide if they want to check them.
As such, there is a lot of stuff in
this I-D that could use a lot of review from SMTP experts.
You say you are reluctant to debate the shortcomings of SPF (many of
which are shared by similar schemes), yet you ask for review. About the
only way that makes sense is to use the review to document the flaws in
SPF.
I have already received several helpful corrections and suggestions
due to this most recent round of reviews. My reluctance to debate the
known issues with SPF is based on seeing many other long rants such as
you have given. I very much doubt that I can change your mind, and
since you have only raised very old and well understood arguments, I
doubt that there is much that I will learn from you on this particular
subject.
-wayne