spf-discuss
[Top] [All Lists]

Re: [spf-discuss] Re: Another test case for the test suite...

2007-01-10 11:27:44

On Wed, 10 Jan 2007, Julian Mehnle wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

William Leibzon wrote:
Julian Mehnle wrote:
The more important problem (as I discussed in my last mail in this
thread from 5  minutes ago) I think is what to do if both types are
queried but the DNS queries' statuses differ.

Local preference of the system doing the check - they must choose either
of the record. If there were errors in checking one of the records, I'd
choose the one that did not cause an error. If one of the records
resulted in fail (as in ip address not in the list of sources that send
email for given domain) and other is pass on the safe side its probably
better to choose pass. Its possible that complex-enough anti-spam system
that does not make immediate reject/accept decisions (unlike mail server
doing test right after MAIL FROM) could use result from both TXT and
TYPE99 when they differ in it spam score computation structure. All of
those are of course corner-cases.

You are missing the point that this discussion is particularly about one
query returning RCODE 0 but no "v=spf1" records and the other query
returning RCODE != 0/3 or timing out.  In that case there is no usable
SPF record.

This is just another corner-case of similar scenarios. Since dns is
UDP protocol, there is no guarantee that you'd receive an answer for
your query, so resolver would typically try again from different NS
server when first one times out. Even though different NS servers
should all be in sync with each other, this can not guarantee a unique
and consistent answer at the recipient side (and not only due to errors with publishers but also due to NS set itself being data that has been cached from previous request and it may have changed too).

Now as far as when you have no answer about query for SPF/TYPE99
record type, you can not make an assumption that there is a valid
v=spf1 record there as its possible that future versions of protocol
would have different record type in there. Best you can do is return
TempFail if there was in fact timeout but I'd consider it ok when
None is given too since you do have answer from one of the alternate
paths for record resolution (and NODATA answer is ok answer in DNS).

BTW, I actually did not describe it well. The issue is not when
the publishers dont keep their records in sync i.e. its not really
the case they they modify one record but not the other - the issue
that is when publisher makes a revision the original data for one
of the records may already have been cached somewhere else without
2nd record type having been cached there. Plus to that that different
dns servers (that you might have at different listed NS) do not
behave the same and while one server might think its nice for them
to have added an extra "related" data in ADDITIONAL section (i.e.
imagine a dns server that adds SPF into ANSWER when you made a request
for TXT or the other way around). All of this results in that query
might not give consistent results at the recipient side. This type
of inconsistency is an issue that pops up in lots of places and is
also issue one of the more complex issues with DNSSEC protocol implementation and deployment because during key rollover you want to be able to deal with such possibility of inconsistency and not give inappropriate failures.

--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net

-------
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

<Prev in Thread] Current Thread [Next in Thread>