Re: overall HELO FAIL

Yes I totally agree.... As far as I'm concerned if a domain has SPF records defined then a mail server either has permission to send email for that domain or it doesn't. So if the SPF records exist then there is PASS and FAIL. I really don't get why someone would use "~all" or "?all".  If you're going to do that, just don't use SPF.


Hector Santos wrote:

----- 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






-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper!  http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription, 
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
  

--

---

Dennis Willson
taz(_at_)taz-mania(_dot_)com
taz(_at_)scubatech(_dot_)org

www.taz-mania.com

Ham:	KA6LSW
GMRS:	WPSJ953
SCUBA:	Rescue, Wreck, Night, EANx, Nitrox Blender, UW Photographer, Equip, Altitude

Life should not be a journey to the grave with the intention of arriving safely in a nice looking and well preserved body, but rather to skid in broadside, thoroughly used up, totally worn out, and loudly proclaiming, "WOW! WHAT A RIDE!"

---

Sender Policy Framework: http://spf.pobox.com/ Archives at http://archives.listbox.com/spf-discuss/current/ Read the whitepaper! http://spf.pobox.com/whitepaper.pdf To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com