----- Original Message -----
From: "Julian Mehnle" <bulk(_at_)mehnle(_dot_)net>
Newsgroups: spf.-.sender.policy.framework.discussion
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Friday, May 27, 2005 5:08 PM
Subject: Re: [spf-discuss] overall HELO FAIL
It seems we lost track of the many council review requests, which indeed
have reached a somewhat inflationary use. We will try better next time,
but in the meantime please try to stick to discussing things
systematically and objectively. If at all possible, we really should
decide things by argument, not by voting.
My opinion on all this:
Frankly, what has gotten me to have a closed ear (or blind eye) for most
recent discussions here, is this disturbing direction to "define"
administration policy when in fact, as far as SPF is concern, all I want
to know if is that machine is authorized to use the domain name.
When I read snippets from the "council", well, quite frankly, it turns me
off. Items are discussed as if they will dictate how servers will behave.
So I ignore it.
It is either a yes or no answer and if its an indeterminate condition, then
its simply a NO-DECISION on the SERVER part. The server moves on to
whatever else is available, if any.
In order words, the sender should not be trying to tell the server "what to
do" and this is where I draw the line. You guys seem to be expressing the
idea that SPF is going to be used the "only" tool. No, we know it isn't.
It is only 1 small part of a total framework of a decision making process
and hopefully, an automated process. Not something that moves the burden to
receivers and users. No we don't need this.
In the end, it is all meaningless because the server will decide what should
be done. Trace fields are important. But it is all still part of a simple
model
PASS
FAIL
INDETERMINATE (someone else decide if possible using trace)
I know that sounds like a no-brainers, but the more I read the discussions,
the more it seems it is a easy to forget distinction. I don't want to write
an AI system. Nor do I want to write Bayesian system. My SMTP
responsibility is to give the customer the following:
SMTP: - Backward compatible system
SMTP: - A reliable way "SMTP method" to validate the 2821 parameters
ADMIN - Additional ADMIN hooks to analyze 2821 parameters
SMTP: - Non-tampering of data reception
ADMIN - Additional ADMIN hooks to analyze 2822 data
I think Andrew Newton clearly stated in MARID just the other day when he
said the SPF specs should focus more on the technical framework. I agree.
I am looking for a solid SMTP automated concept. If the SMTP process can
not do it, then you provide ADMIN features to decide if he wants.
If you guys want this SPF spec to be "endorsed" by the IETF cogs, then you
need to understand the weakness, present it and provide a workaround,
recommendation, etc. Don't allow the pundits to use the "missing"
considerations as their reason for living. Remember, these guys are for a
most part a common group so the idea of a negative or positive "'consensus"
is pretty limited to a small group, and often vocal small group. It isn't a
consensus of the entire population.
SPF 1.0 is simple. Clearly layout the "AUTOMATED" specs. Clearly layout
the potential issues and layout the recommended considerations to address
them. But leave any subject and fuzzy decision making process out of it.
Subjective concepts will never be considered "reliable" enough to be trust
worthy by the server. I am not saying it should be removed. I am saying,
it needs to be presented as the possible issues that IMPLEMENTATORS need to
consider. Think in terms of the above model I presented. I need to what
parts of SPF fit into the SMTP part and what parts of SPF fit into the ADMIN
part.
Anyway, my two pennies for the day. :-)
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com