spf-discuss
[Top] [All Lists]

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

2007-01-11 22:06:27
In <200701120014(_dot_)14557(_dot_)julian(_at_)mehnle(_dot_)net> Julian Mehnle 
<julian(_at_)mehnle(_dot_)net> writes:


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 agree that this is probably a spec bug and that it should look like
the above table.

The primary reason that I think that the above *should* be right is
because of the desire for backwards compatibility with earlier
implementations and specs that didn't include type99 checking.  I
think backwards comparability is very important.


As I've mentioned before, the current spec doesn't say that if you
query for both RR types some of the time, you have to query for both
RR types all of the time.  Nor does it say that once you start a DNS
lookup for a RR type that you have to let it complete and pay
attention to the results.

As a result, you can the above desired results by playing somewhat
fast and loose with the spec and recognize that a timeout on a TXT
record is "special" and ignore the results of the type99 query, but
otherwise proceed with the logic outlined in RFC 4408 for doing both
RR type queries.  You are just doing some "extra data processing"
before you actually do the "real SPF checking".  *wink* *wink*

I'm not sure that it is a really strong nor defensible position to
take if someone tried to argue a strict interpretation of the RFC
compliance.


-wayne

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