In <NGBBLEIJOEEEBMEIAPBKOEGAIJAA(_dot_)scott(_at_)kitterman(_dot_)com> Scott
Kitterman <spf2(_at_)kitterman(_dot_)com> writes:
Silent incomplete processing
[limits on MX and PTR lookups snipped]
Yes, those are "silent". So is "v=spf1 a:invalid.tld -all" and
"v=spf1 ip4:10.0.0.1 -all"
Examples:
(wayne(_at_)backbone) $ spfquery -helo=netcom.midwestcs.com -ip=207.69.200.66
pass
(wayne(_at_)backbone) $ spfquery -helo=netcom.midwestcs.com -ip=207.69.200.66
fail
(wayne(_at_)backbone) $ spfquery -helo=invalid.midwestcs.com -ip=207.69.200.66
fail
(wayne(_at_)backbone) $ spfquery -helo=rfc1918.midwestcs.com -ip=207.69.200.66
fail
(wayne(_at_)backbone) $
The first query passes because the particular MX record is within the
first 10, but the second one fails because bind rotated the list, and
it dropped out of the first 10.
Now when I added all that up, it looked like PermError to me.
Well, that isn't what the spec says.
Remember, PermError was originally named "unknown" and designed to
signal unknown mechanisms. The SPF spec has always had silent
"errors".
As I read the draft, it seems clear to me that more than 10 MX/PTR is a
PermError. Otherwise the protocol is unreliable. Silent errors and
inconsistencies are exactly what we need to avoid and exactly what everyone
was arguing we needed to avoid when I wanted to go back to PermError/Unknown
~ Neutral/None.
That is not how I read the schlitt-spf-classic-02 draft, nor the
mengwong-spf-0[01] drafts.
If you have a time machine, please go back to late 2003 and convince
Meng that the drafts should be changed. Otherwise, we are stuck with
what is, not what people might want to be.
-wayne