----- Original Message -----
From: "Dick St.Peters" <stpeters(_at_)NetHeaven(_dot_)com>
Newsgroups: spf.-.sender.policy.framework.discussion
Right here is the essence of what the shouting is about. Mark lives
in the real world where SPF policies say what senders would like
reeivers to do, but receivers aren't under any obligation to do it
that way. Meanwhile, Hector is stuck trying to design email software
for users of arbitrary receivers, so he wants all receivers using SPF
policies to be the same. I think that's highly unrealistic and that a
BCP rfc is probably the most Hector can expect, and even that will
take a few years of wringing out.
You raised a good point. If you followed my postings over the past two
years, I mentioned on more than one occasions there is are administrative
and Developer philosophical conflicts. Its all deja-vu to me. It has
brought down former MAIL NETWORKS!
But don't you think I have administrators and operators to deal with too?
After all, they are my "boss." We have to accommodate all forms of thinking
and we have been doing so for 20+ years.
My take is simple, unless you don't have minimum consistency, then nothing
else really matters. You have to work with a base line of common ground.
In this case, this was an obvious flaw that fell thru the cracks. If I
would of saw it early on, no doubt, I would brought it up.
The problem is the SPF protocol engine model based on a IP::DOMAIN LMAP
association, having a fixed result from a known list of fixed conditions
suddenly changing due to a NON-SPF methodology for a non-standard
implementation.
To me, that's a no-brainer.
It really has nothing to do with "administrative" interpretations because
that an be easily fixed with the EXPECTATIONS of what he wants to see to
help him make a decision.
For example:
Received-SPF: PASS (...BEST GUESS...)
this only make sense to the BEST GUESS non-standard implementations. These
people will know that a PASS - BEST GUESS means that it was really a
SPF-NONE result (But will the users know that?)
Everyone else, whether it was HUMAN or MACHINE, would not know any better
than what is in its knowledge bank; a Received-SPF: NONE means the domain
has no policy, a Received-SPF: PASS means the domain passed the SPF record
test.
So when I design software, especially mail systems, I've been doing it for
nearly 30+ years, nearly exclusively in the mail/file distribution and
hosting market, I think I have a pretty good feel and balance between what
is programmatically and technically consistent and what is administrative
consistent. I listen to all input. I'm trained to do that.
For me, this one is a no-brainer, yet, based on Daniel's comment, I can
completely see the thinking behind the PERL SCRIPT development and getting
some PASS feedback. Since there was no SPF records to work with, they jumped
over the border to deal with HELO/IP A/PTR correlations which they knew all
along it was not going to be part of the final specification. I can see
that. But the mistake to me was to change NONE to PASS in the Received-SPF:
header. Thats the main inconsistency.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
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