----- Original Message -----
From: "Mark" <admin(_at_)asarian-host(_dot_)net>
Is this a difficult concept to grasp?
What is apparently too difficult to grasp -- for you, at least -- is that
'best-guess' does not change the meaning of PASS one iota: not in the
spec, because it is not even in the spec; and not otherwise, because
'best-guess', per local policy, just broadens the PASS window to a fixed,
'guessed' width = "a/24 mx/24 ptr". It does not change the meaning of PASS
at all. PASS still means PASS. 'best-guess' just assigns a fixed 'width'
to what can PASS.
Huh?
For a standard SPF system, which I hope you realize does not have to be
using this PERL script, will follow the standard specification and a PASS is
a PASS, a NONE is a NONE, It knows nothing about PASS - GUESS!
I believe you are assuming this PERL script is used by everyone and that
every SPF implementation will follow this PERL script model or will read
into something in the standard SPF specification that simply isn't there.
Sorry, this is a obviously flaw by any technical expert interpretation or
stretch of imagination.
I proposed a simple solution. Follow the spec:
Received-SPF: none (....best guess...)
Your perl script will still work and more importantly standard
implementation will understand that a NONE is a NONE, not a PASS.
I have personally never found cause to enable 'best-guess'. But it is in
the nature of receiver policy (the "Your MTA, you rules" adage) that
receivers can accept pretty much all mail they want.
Thats fine, but a standard SPF implementations will not understands this
false PASS notification. It knows nothing about this BEST GUESS because it
is not expecting it. However, it will know a NONE was the REAL result. It
wasn't a PASS.
And as for the Received-SPF header, the only confusion I can
see happen, is when people are misguided enough to
think actual delivery decisions are made upon the
value of that header, instead of during the SMTP dialogue.
No, it has nothing to with FUZZY intepretations. What is mis-guided is to
beleive a NON-STANDARD feature is going to be supported across the board
when in fact, in reality, it is not part of the standard specification.
What is mis-guided is to change the deterministic nature of the SPF
protocol. A PASS is a PASS, a NONE is a NONE. It has nothing to do with an
administrator or user thinks or see.
It is purely about following TECHNICAL SPECIFICATIONS which should not be
confused or twisted with non-standard implementations.
And if people read the Receiced-SPF header, and plainly see "Best Guess"
in that header, and still remain in their confusion, then consider that
perhaps their state of confusion is of a more permanent nature.
Adding extra information for extended implementation is great. But it is
not part of the BASE standard, so it should be CHANGING the meaning of the
SPF result.
Look, if you feel it should be part of the specs, go for it. But until it
is, it should be not be changing the meaning of a NONE result that only the
standard implementation understands. It doesn't understand PASS - BEST
GUESS.
I propose:
Received-SPF: none (....best guess...)
as the logical and consistent solution for this PERL script because what it
is doing now is breaking the standard SPF implementation.
--
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