Re: Problems with spf testsuite and dns specification

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

Stuart, you elegantly managed to avoid answering my main question:

> I am against allowing multiple results for the "multispf{1,2}" test
> cases. As I said, I'd rather resolve the issue by turning the "multiple
> identical records" into "multiple differing records" as follows:
>
> --- rfc4408-tests.yml   (revision 89)
> +++ rfc4408-tests.yml   (working copy)
> @@ -272,10 +272,10 @@
>      - TXT:  V=sPf1 +all
>    example7.com:
>      - SPF:  v=spf1 -all
> -    - SPF:  v=spf1 -all
> +    - SPF:  v=spf1 +all
>    example8.com:
>      - SPF:  v=spf1 -all
> -    - SPF:  v=spf1 -all
> +    - SPF:  v=spf1 +all
>      - TXT:  v=spf1 +all
>    example9.com:
>      - SPF:  v=SpF1 ~all
>
> That would nicely continue to test for RFC 4408 4.5/6 while avoiding to
> accidentally test for RFC 2181 5/1.
>
> Stuart, do you see a problem with this approach?

?

Stuart D. Gathman wrote:
> On Sat, 16 Jun 2007, Julian Mehnle wrote:
> > I don't see that as a good idea.  Stub resolvers should always try to
> > conform to the same RFCs as live resolvers, and any ambiguities in
> > those RFCs must be considered legal by the RFC 4408 test suite, i.e.,
> > it must NOT test them.
>
> The point is, a live resolver *just might* return multiple identical
> records.  In that case (as unlikely as it may be in practice), rfc4408
> says the result is PermError.  So this is a legitimate thing to test
> for.

No, it isn't.  Testing it like the test suite currently does means 
implicitly testing for obeyance or non-obeyance of a "should" in RFC 2181.  
A resolver (be it live or stub) may very well combine multiple identical 
records into a single one and NOT be incompliant with RFC 4408!  Or are 
you saying that using a DNS resolver/cache that conforms to RFC 2181 5/1 
makes an SPF implementation _incompliant_ with RFC 4408?

> The more unlikely, the more important to test for it.

This has nothing to do with probabilities.  Both combining and not 
combining multiple identical records is legal according to RFC 2181.

> > > The inconsistency is a red herring.  You could publish multiple
> > > non-identical records with differing TTL and get a similar
> > > inconsistency where resolvers could see either or both depending on
> > > timing.
> >
> > That's true.  But it still doesn't mean that the RFC 4408 test suite
> > should, implicitly or explicitly, test for compliance with some
> > "should" in RFC 2181.
>
> The MUST is in RFC 4408.

But it is obviously relative to RFC 2181 5/1.  _Why_ can a stub resolver 
(or test suite driver) not conform to RFC 2181 5/1?  I don't see this 
written anywhere.  Why would using a combining _live_ resolver be legal, 
whereas using a combining _stub_ resolver would not?

> Now if you feel that RFC 4408 didn't really mean to mandate a permerror
> for multiple records when they are identical (in light of 2181), then we
> can discuss that.

No, RFC 4408 is very clear: if the SPF implementation encounters multiple 
records (identical or not), it must throw a PermError.  However, RFC 4408 
does NOT forbid SPF implementations to use DNS resolvers that combine 
identical records, causing the implementation to NOT encounter multiple 
identical records.

Normally I'd agree that such a prohibition would be implicit -- if it 
wasn't an official DNS RFC recommending that it be done!

> We can also allow both results in the test suite to reflect that lack of
> consensus.

Well, if we don't achieve consensus, then that's what we may have to do, 
but I really think this is outside the scope of the RFC 4408 test suite 
and thus should not be tested as it is being tested now.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGdHTHwL7PKlBZWjsRAhHBAKCO9gcZ3hIHEFmjBjwYq8fUaSZLGwCg9pLQ
1fYC/GeecJu05wOOzqOEE/o=
=hgpX
-----END PGP SIGNATURE-----

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