On Tue, 6 Apr 2004, Stuart D. Gathman wrote:
markjr(_at_)spitfire:~$ host -t txt easydns.com
easydns.com text "v=spf1 mx ptr ip4:205.210.42.0/24 ip4:216.220.40.240/29
ip4:66.207.199.35/32 include:myprivacy.ca ptr:opensrs.net ~all"
And I'm testing from support(_at_)easydns(_dot_)com off IP 216.40.33.45
(mp.opensrs.net) we get from declude:
This passes with the perl Mail::SPF::Query and libspf-alt, but failes
with "unknown" using libspf. I can't check the PHP imlemenation on
infinitepenguins because the website is currently down. :-<
Gets 'neutral' with Python spf.py 1.6. I suspect the tricky issue is
that ptr occurs twice. When it fails the first ptr, it seems to ignore
the second ptr and gets to the "~all". I'll debug the Python version.
It is the include. There is a subtle issue here.
When it gets to the include:myprivacy.ca, which is
"v=spf1 a:tex.privateworld.com"
the result is "neutral" - and that is the result of the evaluation.
This is consistent with this paragraph for 'include' in the RFC:
This mechanism matches when the new query result returns a pass, and
doesn't match when the result is fail. However, if the new query
returns none, unknown, or error, then processing of the entire SPF
query stops immediately and returns the unknown or error result.
However, there is a following table which gets specific for the neutral and
softfail cases on an include:
pass => match, return the prefix value for "include"
fail => no match, continue processing
softfail => no match, continue processing
neutral => no match, continue processing
error => error, abort
unknown => unknown, abort
none => unknown, abort # see below
So, I can see why the implementors of libspf and spf.py were confused,
but I believe the correct result is 'pass'.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Very few of our customers are going to have a pure Unix
or pure Windows environment." - Dennis Oldroyd, Microsoft Corporation