Re: Re: Problems with spf testsuite and dns specification

Julian Mehnle ha scritto:
> Stefano Bagnara wrote:
>> Can someone add this issue to the Errata page
>> (http://www.openspf.org/RFC_4408/Errata) or change the testsuite to not
>> check this?
> 
> In order for this to become an erratum to RFC 4408, it would have to be 
> approved by the council.  I can table this for the next council meeting, 
> even if -- as I said -- I don't think that would be the correct solution.
> 
> As far as the test suite is concerned, a change can eventually happen, but 
> it won't be "fast".  Perhaps in a week or two.  But see below.

A week or two would be fast enough :-)
I just wanted to be sure that this won't be lost...

>> I bet that most "compliant" SPF implementations currently use resolver
>> libraries that compact the results
> 
> (For what it's worth, I somehow doubt that client-side unification of 
> multiple identical RRs is widely implemented in DNS _resolvers_.)

A big problem are DNS caches: as far as I understood BIND does compact
identical RRs, so any user using an SPF client against a BIND cache (90%
of users around the world?) will have big probability to never see
identical duplicate RRs.

So this lead to inconsistent result when someone publishes multiple
identical records: you cannot tell if users will receive PermError or
they will accept it... IMHO unpredictable result is bad for a
specification directive, that's why I think a more consistent approach
would be to accept multiple identical records as a single records and to
not fail. This way the dns caches behaviour will not alter the SPF
processig/result.

Of course this is something the council will have to decide and I'm ok
with most solutions, but I need a solution ;-)

>> and in real use cases they probably fail to recognize identical duplicate
>> records: are these implementations being tested against real dns servers
>> or the resolution process is mocked?
> 
> I currently don't know of any RFC 4408 compliant implementation that tests 
> against live DNS.  There may be some, but I don't know any.

In jSPF we created a DNS server that takes the data from the test suite
and provide results according to that data to the client. So the client
resolving library is also tested for real. Doing this work I found out
the duplicate record issue ;-)

I think that the "mockable" DNS Server we created might also be useful
to spf team to better test implementations without mocking the
resolution mechanism in the library.

>> How can I help to have a fast solution for the test suite? I'd like to
>> complete our jSPF library and make sure it is compliant and this issue
>> is critical.
> 
> Until the issue is resolved officially, you can instruct your jSPF test 
> suite driver to skip the problematic tests, explicitly declare in your 
> documentation that you cannot comply with those tests, and explain why.

This would weak the test suite. I think that at least adding "cloned"
tests for multispf tests replacing multiple identical records with
multiple different records would help differentiating the problem and
this seems to be a task that you can approach without council
requirements... WDYT?

Add this to the tests:

  multispf3:
    description: >-
      Multiple records is a permerror, even when they are identical.
    spec: 4.5/6
    helo: mail.example1.com
    host: 1.2.3.4
    mailfrom: [email protected]
    result: permerror
  multispf4:
    description: >-
      Older implementations will give pass because there is a single
      TXT record.  But RFC 4408 requires permerror because the SPF
      records override and there are more than one.
    spec: 4.5/6
    helo: mail.example1.com
    host: 1.2.3.4
    mailfrom: [email protected]
    result: [permerror, pass]

and in the zone

  example10.com:
    - SPF:  v=spf1 -all
    - SPF:  v=spf1 +all
  example11.com:
    - SPF:  v=spf1 -all
    - SPF:  v=spf1 +all
    - TXT:  v=spf1 +all


Stefano

-------------------------------------------
-----------------------------------------------------------------------
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?member_id=6959932&user_secret=62b4c45f
Powered by Listbox: http://www.listbox.com