On Thu, 17 Nov 2005 20:37:06 -0500 "Hector Santos"
<spf-discuss(_at_)winserver(_dot_)com> wrote:
----- Original Message -----
From: "Frank Ellermann" <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>
Hector Santos wrote:
Sorry, Frank, call me what you like.
LOL, better not, and I wouldn't try to report "best guess"
in Received-SPF. But I've no problem if others do this as
long as it clearly says _guess_
So now your mail filter needs to look for something that is not part of the
SPF standard?
Received-SPF: None
Received-SPF: Pass
Received-SPF: Fail
Received-SPF: Softfail
Received-SPF: Neutral
Received-SPF: TempError
Received-SPF: PermError
The SPF specs are:
result = "Pass" / "Fail" / "SoftFail" / "Neutral" /
"None" / "TempError" / "PermError"
There are not consideration for "GUESS"
The above are the only tags that the parser will look for per SPF
specification.
Why not just do it right?
Received-SPF: PASS-Best-Guess
Received-SPF: PASS-Maybe
Received-SPF: PASS-No-Fail-I-Giveup
Received-SPF: PASS-SnakeEye-Craps
Received-SPF: PASS-GAS
Of course it's not specified, SPF is about sender policies,
not about receiver policies.
Exactly, so if there is NO SPF policy, the only real result per
specification is:
Received-SPF: None
But from a receiver's POV it can make sense to use
such "best guess" approaches.
And a bear does it business in a forest, sure. Of course, it can anything
it like, but if it doesn't follow the SPF specs and adds stuff that isn't
PART of the specs, then it really isn't compliant and it makes the matter
worst for everyone down the pike. It screws up 3rd party Mail Filter
authors
because when they parse for PASS, they didn't EXPECT it to mean it was
anything but a a SPF NONE condition and they didn't expect PASS may come
with a "BEST GUESS"
This is telling implementations they need to look for the word "GUESS"
because the PASS was really a lie. If you want implementatios to follow
this, then add it to the spec, and do it right:
Received-SPF: None (gmail.com: CLIENT MATCH
HELO domain abusecore.charter.net
matches IP 209.225.29.51)
But for GMAIL.COM to say instead:
Received-SPF: pass (gmail.com: best guess
record for domain of root(_at_)abusecore(_dot_)charter(_dot_)net
designates 209.225.29.51 as permitted sender)
is completely wrong and since there is no standard, others may follow what
GMAIL.COM did.
The trurh was: It was not a pass and the root domain DID NOT designate the
address as a permitted sender because there was NO sender policy.
Come on folks. Stuff like this doesn't help SPF. It hurts SPFs.
I agree with Scott. if this perl library is suppose to be a standard
example
of an SPF implementation then a) either it needs to remove this feature, or
b) correct it to say something lie above with Received-SPF: None, and c)
more importantly, add it to the specifications because this is something
anyone following the specs will not know about.
Best guess was one of Meng's ideas that he put in M:S:Q. it's never been
in any of the SPF specs. Let's not start now.
It's in pyPSF as Stuart said, but you have to turn it on. For the limited
uses Stuart describes, it has some utility. For more general use, I don't
think it's appropriate.
Let's get Craig's M:S:Q updates up on CPAN and send out an announcement on
spf-deployment.
Any volunteers to test the updates with SpamAssassin?
Scott K
-------
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