Seth Goodman wrote:
That's what they're supposed to have. What they actually have may
be different.
Yes, but that's their problem to sort out. A receiver sending both
queries is free to pick the first good reply they get for real. The
weird idea to wait for both replies and check that they're identical
was fortunately killed.
it seems more sensible to treat both queries the same.
Stuart explained why this theoretical approach could cause problems
for domains with broken name servers not supporting SPF RRs.
[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:
- We already found that the case "timeout" and the case "rcode is
neither 0 nor 3" can be joined.
- My idea to split "no record" from "no v=spf1" was utter dubious.
We can also join this, getting a very clear and simple 2*2 table:
| 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.
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. Not good enough for broken servers if
the error for the SPF query arrives first. So maybe a less naive
implementation always sends the TXT query before the SPF query (?)
Or it ignores an error or timeout for the SPF query, using for that
special case only the TXT reply (even if it comes later). As soon
as there is a good reply in the cache that's anyway faster.
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 should err on the side of protecting the domain name (temperror)
rather than mail delivery (none).
It's not that simple. There are folks who don't publish v=spf1
policies, let alone create SPF RRs. Delaying their mail with a
TempError about something they've never heard of (RFC 4408) caused
by a bug about type99 in a piece of magic they don't know (the DNS
operated by their Web hoster or similar) would be rather annoying.
Very near to "net abuse" if they'd forget that nobody's forced to
accept their mail.
Frank
-------
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