-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Frank Ellermann wrote:
[timeout or rcode neither 0 nor 3]
If you query for both records and either one gives the above result,
that is also a temperror. If you don't like this possibility, don't
query both record types
IMO it makes no sense to annoy senders with broken name servers with
a TempError for the SPF query after you got any "non-error" for the
TXT query.
Next attempt with one of those tables:
[...]
| SPF no record | SPF timeout or
| SPF no v=spf1 | rcode not 0/3
-----------------+----------------+---------------
TXT no record | NONE | NONE
TXT no v=spf1 | |
-----------------+----------------+---------------
TXT timeout or | NONE | TempError
rcode not 0/3 | |
That's symmetrical, therefore it should be compatible with the spec.
You keep arguing along all kinds of theoretical lines, but you also keep
ignoring this one significant aspect of reality -- the one that originally
incited this thread:
If you query both TXT and SPF types, and the SPF query returns a "no
record/no v=spf1" answer and the TXT query times out, you simply cannot
reasonably assume there is no TXT-type SPF record, even if such a behavior
was compliant to the RFC or made some table oh-so-symmetrical... By far
most SPFv1 records have been published using the TXT type.
(Now you may ask, what if the implementation chose to query the SPF type
only? Then "None" would still be returned, wouldn't it? Well, yes, but
this is a purely theoretical case as there aren't any such SPFv1 implemen-
tations out there, and there probably never will be.)
I still think the spec has a bug. It should have looked like this instead:
| SPF no record | SPF timeout or
| SPF no v=spf1 | RCODE not 0/3
-----------------+----------------+---------------
TXT no record | None | None
TXT no v=spf1 | |
-----------------+----------------+---------------
TXT timeout or | TempError | TempError
RCODE not 0/3 | |
I've no clue how Stuart has implemented his tolerance for broken
name servers. My naive approach would be take whatever I get first
(after two queries) as the "real" reply, not waiting for a "better"
or conflicting second reply.
This isn't a good approach if your objective is discovering data. "Place 1
says no-data-here, so let's not wait what place 2 says. We'll just assume
there's no data at all." Sorry, it doesn't make any sense.
But this is an implementation detail dealing with the reality of
broken name servers, it's far beyond conformance testing. Wrt the
spec. it should be okay to use alwyas the first result, no matter
what it is (including errors for the SPF query).
We're (well, _I_ am) talking about the reverse case... *sigh*
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFFptLWwL7PKlBZWjsRAoljAJwKyWENCh9VwKgd33qnnbCUudXH7wCfeO05
fCQKekqxn+blaam6YEOuQhQ=
=truE
-----END PGP SIGNATURE-----
-------
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/?list_id=735