Mailing List Archive

On Tue, 12 Jun 2007, Stefano Bagnara wrote:

> The specification should probably be changed so the permerror is only
> required if multiple SPF records are found and they are different or
> multiple TXT records are found and they are different. If 2 TXT or 2 SPF
> records are found and are identical then it is a matter of server and
> client implementations to decide wether to consolidate the 2 records
> into a single record or not, so the SPF specification should not suggest
> a behaviour depending on the dns client/server used to do the lookup.

So, you're saying that if I put this in my DNS:

foo IN TXT "foobar"
IN TXT "foobar"
IN TXT "foobar"

That looking up TXT records for "foo" could return anywhere from 1
to 3 records?

Nevertheless, the SPF spec says that when there are multiple TXT
records beginning with "v=spf1", then the correct result is PermError.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

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

Stuart D. Gathman ha scritto:
> On Tue, 12 Jun 2007, Stefano Bagnara wrote:
>
>> The specification should probably be changed so the permerror is only
>> required if multiple SPF records are found and they are different or
>> multiple TXT records are found and they are different. If 2 TXT or 2 SPF
>> records are found and are identical then it is a matter of server and
>> client implementations to decide wether to consolidate the 2 records
>> into a single record or not, so the SPF specification should not suggest
>> a behaviour depending on the dns client/server used to do the lookup.
>
> So, you're saying that if I put this in my DNS:
>
> foo IN TXT "foobar"
> IN TXT "foobar"
> IN TXT "foobar"
>
> That looking up TXT records for "foo" could return anywhere from 1
> to 3 records?

http://www.dns.net/dnsrd/rfc/rfc2181.html#5.%20Resource%20Record%20Sets

It says "Servers should suppress such duplicates if encountered". Most
servers will return 1 single IN TXT "foobar".

So if they are identical any server could change it, any caching server
could change it. According to Brian Wellington BIND (AFAIK the most
widely adopted dns server) does consolidate similar records.

> Nevertheless, the SPF spec says that when there are multiple TXT
> records beginning with "v=spf1", then the correct result is PermError.

That's what I'm trying to fix. IMHO it is correct when the records are
different, but when they are identical it is a matter of what DNS server
(servers) and what dns clients are in the resolution chain to know if
you will receive one or multiple identical records. The SPF spec should
not rely on this: the DNS spec does not allow such distinction to be
made and SPF is a DNS based protocol.

Stefano

PS: please note that I found this issue when I tried to populate my
server with the data needed by the testsuite and even if I placed there
multiple identical IN SPF records it was returing me a single record and
my implementation failed. Then I patched my dns server to return
multiple records and I still had a failure because also my dns client
was consolidating the identical records... I had to patch also the
client and fill the bug report to dnsjava author that as you saw has
good motivation to not change the current behaviour.

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

On Tue, 12 Jun 2007, Stefano Bagnara wrote:

> > Nevertheless, the SPF spec says that when there are multiple TXT
> > records beginning with "v=spf1", then the correct result is PermError.
>
> That's what I'm trying to fix. IMHO it is correct when the records are
> different, but when they are identical it is a matter of what DNS server
> (servers) and what dns clients are in the resolution chain to know if
> you will receive one or multiple identical records. The SPF spec should
> not rely on this: the DNS spec does not allow such distinction to be
> made and SPF is a DNS based protocol.

If some client library *did*, however, return multiple identical records,
then the correct result is PermError. Your problem is that when testing
through a live DNS server, it is difficult to reproduce this situation.

Here are some possible resolutions:

1) tag selected tests as "optional for live DNS testing".

2) Add multiple results for tests with multiple identical records.
There is certainly no ambiguity in using one of 2 duplicate SPF
records, so implementations can be considered justified in bending the
current spec a little for this case.

3) Add an errata for the spec addressing the case of duplicate records.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

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

Stuart D. Gathman ha scritto:
> On Tue, 12 Jun 2007, Stefano Bagnara wrote:
>
>>> Nevertheless, the SPF spec says that when there are multiple TXT
>>> records beginning with "v=spf1", then the correct result is PermError.
>> That's what I'm trying to fix. IMHO it is correct when the records are
>> different, but when they are identical it is a matter of what DNS server
>> (servers) and what dns clients are in the resolution chain to know if
>> you will receive one or multiple identical records. The SPF spec should
>> not rely on this: the DNS spec does not allow such distinction to be
>> made and SPF is a DNS based protocol.
>
> If some client library *did*, however, return multiple identical records,
> then the correct result is PermError. Your problem is that when testing
> through a live DNS server, it is difficult to reproduce this situation.
>
> Here are some possible resolutions:
>
> 1) tag selected tests as "optional for live DNS testing".
>
> 2) Add multiple results for tests with multiple identical records.
> There is certainly no ambiguity in using one of 2 duplicate SPF
> records, so implementations can be considered justified in bending the
> current spec a little for this case.
>
> 3) Add an errata for the spec addressing the case of duplicate records.

IMHO is not so smart to have the SPF spec requiring a behaviour from
library implementors while we already know that the behaviour will
change from pass to permerror depending on the dnsserver the user is using.

This is because indipendently from what the SPF record publisher
publishes on his own server the final result will depend also on the
caching server you are querying.

IMHO it would be FAR BETTER to add a clarification to the spec
explaining this particular scenario and allowing the implementors to
treat multiple identical dns record as one single record and this way
allow them to not return PermError *IF* the multiple records are identical.

So #2 and #3 are acceptable to me. #1 is not a correct solution IMO.

Stefano

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

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

Stefano Bagnara wrote:
> http://www.dns.net/dnsrd/rfc/rfc2181.html#5.%20Resource%20Record%20Sets
>
> It says "Servers should suppress such duplicates if encountered". Most
> servers will return 1 single IN TXT "foobar".

You bring up an interesting point. I wasn't aware of this before, although
I'm quite sure I do have read this part of RFC 2181 before.

> > Nevertheless, the SPF spec says that when there are multiple TXT
> > records beginning with "v=spf1", then the correct result is PermError.
>
> That's what I'm trying to fix. IMHO it is correct when the records are
> different, but when they are identical it is a matter of what DNS server
> (servers) and what dns clients are in the resolution chain to know if
> you will receive one or multiple identical records. The SPF spec should
> not rely on this: the DNS spec does not allow such distinction to be
> made and SPF is a DNS based protocol.

I agree. This is optional behavior in the DNS specs, and SPF must tolerate
all legal DNS behavior.

In particular, this means that the test suite must not inherently require
DNS implementations to choose one option over the other(s). If a DNS
implementation and its RFC 4408 test suite driver choose to collapse
multiple identical records, then that must not make the test suite data
invalid as a result.

This is NOT an issue with RFC 4408 itself, and making any errata to it with
regard to this issue would be wrong. Neither should this ever be seen as
an issue with SPF implementations themselves (as opposed to, for example,
with their DNS bindings). [.I.e., if an SPF implementation gets two
_identical_ SPF records for the same DNS name from their DNS binding, then
it must consider them as redundant and throw a PermError. If some part of
the DNS implementation chain (from the domain's name server to the SPF
implementation's DNS client) consolidates them, then the SPF implemen-
tation must handle that as a single SPF record.]

Instead, the zonedata used by the test cases "multispf1" and "multispf2"
should be changed to feature slightly differing records in order to
respect valid DNS behavior while still being able to prove the test cases'
points.

Stuart, do you see any reason why having such tests with multiple
_identical_ -- as opposed to merely multiple, but differing -- SPF records
is important?

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

iD8DBQFGbytGwL7PKlBZWjsRAqSQAJ4/twgEMgVEwE3b6/rzAfZuJ9j69ACeOy55
FEoGwgdOLQ5otRWLy8v+EpI=
=wuvC
-----END PGP SIGNATURE-----

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

On Tue, 12 Jun 2007, Julian Mehnle wrote:

> Stuart, do you see any reason why having such tests with multiple
> _identical_ -- as opposed to merely multiple, but differing -- SPF records
> is important?

*Especially* if there is logic invoked only upon duplicates, you want
to check for a correct result. If the spec should not have an errata
for this, then the best resolution is probably to allow both results for
duplicate records.

Now we can argue over which result (PermError/other) should be the
preferred result.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

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

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

Stuart D. Gathman wrote:
> On Tue, 12 Jun 2007, Julian Mehnle wrote:
> > Stuart, do you see any reason why having such tests with multiple
> > _identical_ -- as opposed to merely multiple, but differing -- SPF
> > records is important?
>
> *Especially* if there is logic invoked only upon duplicates, you want
> to check for a correct result. If the spec should not have an errata
> for this, then the best resolution is probably to allow both results for
> duplicate records.

No -- assuming this isn't something the SPF spec should care about, then
why is this something the test suite needs to check? Doesn't it suffice
to check only the weaker case where multiple but differing records exist?
(After all, the case is not weaker from SPF's PoV, only from that of DNS.
But we aren't testing the correctness of DNS, just that of SPF.) What
does checking the multiple-identical-records case give us that checking
the weaker case doesn't?

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

iD8DBQFGb6BJwL7PKlBZWjsRAoW7AKCbweImnXKpw/M0wu9z5UW6lBKhZQCgvbBg
QkhGtUgRNZXmRbQ6fyCZcqI=
=i8hi
-----END PGP SIGNATURE-----

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

Julian Mehnle ha scritto:
> Stuart D. Gathman wrote:
>> On Tue, 12 Jun 2007, Julian Mehnle wrote:
>>> Stuart, do you see any reason why having such tests with multiple
>>> _identical_ -- as opposed to merely multiple, but differing -- SPF
>>> records is important?
>> *Especially* if there is logic invoked only upon duplicates, you want
>> to check for a correct result. If the spec should not have an errata
>> for this, then the best resolution is probably to allow both results for
>> duplicate records.
>
> No -- assuming this isn't something the SPF spec should care about, then
> why is this something the test suite needs to check? Doesn't it suffice
> to check only the weaker case where multiple but differing records exist?
> (After all, the case is not weaker from SPF's PoV, only from that of DNS.
> But we aren't testing the correctness of DNS, just that of SPF.) What
> does checking the multiple-identical-records case give us that checking
> the weaker case doesn't?

I agree, but

I also think that if you don't want to change the specification about
multiple identical records then the current failing tests should be kept
and both results should be accepted (the PermError and the real result
of the single spf record, that I didn't test if it is Pass or what
else). This way in that test comment we will record this issue.

Stefano

PS: I still think that it would be better to change the spf spec so that
multiple identical records are considered a single record by spf, but I
can live with the above change.

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

Can someone add this issue to the Errata page
(http://www.openspf.org/RFC_4408/Errata) or change the testsuite to not
check this?

I bet that most "compliant" SPF implementations currently use resolver
libraries that compact the results 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?

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.

Stefano

Julian Mehnle ha scritto:
> Stuart D. Gathman wrote:
>> On Tue, 12 Jun 2007, Julian Mehnle wrote:
>>> Stuart, do you see any reason why having such tests with multiple
>>> _identical_ -- as opposed to merely multiple, but differing -- SPF
>>> records is important?
>> *Especially* if there is logic invoked only upon duplicates, you want
>> to check for a correct result. If the spec should not have an errata
>> for this, then the best resolution is probably to allow both results for
>> duplicate records.
>
> No -- assuming this isn't something the SPF spec should care about, then
> why is this something the test suite needs to check? Doesn't it suffice
> to check only the weaker case where multiple but differing records exist?
> (After all, the case is not weaker from SPF's PoV, only from that of DNS.
> But we aren't testing the correctness of DNS, just that of SPF.) What
> does checking the multiple-identical-records case give us that checking
> the weaker case doesn't?
>

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



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

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

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.

> 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_.)

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

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

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

iD8DBQFGc90YwL7PKlBZWjsRAqccAJ9vHOMRoprzxmwlMOkqhUjZsTmPhACcCMmr
HD3x5BxjsFRa3rNpyBTjwI4=
=luAj
-----END PGP SIGNATURE-----

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

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: foo@example10.com
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: foo@example11.com
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=1311533&user_secret=456ecacd
Powered by Listbox: http://www.listbox.com

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

Stefano Bagnara wrote:
> Julian Mehnle ha scritto:
> > (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.

Good point. But this is still besides the main point. This shouldn't be
an issue of SPF just like SMTP doesn't define what to do about multiple
identical MX records. This PoV is even strengthened by RFC 2181 pointing
out that it is up to servers to suppress any multiple identical RRs.

We'll see if the council agrees to not have the test suite unnecessarily
check for a specific resolution of this ambiguity. I hope it will.

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

This is an interesting approach. Can you package up this "mockable DNS
server" and document its use? I could see linking to it from the official
test suite webpage then.

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

Well, you can do that as long as you don't claim compliance to the official
RFC 4408 test suite. But it may be "good enough" for now, as long as you
document exactly what the jSPF test suite is doing.

I'd advise against modifying rfc4408-tests.yml, though. You could create a
separate rfc4408-tests-jspf.yml (or so) with additional tests.

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

iD8DBQFGc+uPwL7PKlBZWjsRAqm/AKCLQzXsTdNwyRS1qhVmIS9DOMBkXACguDH3
s5EDwac8UPD2GoqBCgasbd0=
=eNXz
-----END PGP SIGNATURE-----

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

On Sat, 16 Jun 2007, Stefano Bagnara wrote:

> 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

Publishing multiple SPF records is forbidden by rfc4408, whether they
are identical or not. The effect of your issue is that often
an implementation can't tell that multiple records were published
so as to return the required PermError. That is the only reason that
an alternate result would be allowed in the test suite - because with
live DNS, you can't tell whether a cache combined identical records.
Ideally, you would return a Permerror because multiple records are forbidden
by the RFC, but ideals are not always attainable attainable in practice.

That is why I would like to tag tests for liveDNS vs stubbed resolver.
The stubbed resolver can test for the correct result when multiple identical
records are in fact passed through. Just because the DNS you are testing
with happens to combine them, doesn't mean that in production you won't
run into a cache that doesn't.

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.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

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

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

Stuart D. Gathman wrote:
> On Sat, 16 Jun 2007, Stefano Bagnara wrote:
> > 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
>
> Publishing multiple SPF records is forbidden by rfc4408, whether they
> are identical or not. The effect of your issue is that often
> an implementation can't tell that multiple records were published
> so as to return the required PermError. That is the only reason that
> an alternate result would be allowed in the test suite - because with
> live DNS, you can't tell whether a cache combined identical records.
> Ideally, you would return a Permerror because multiple records are
> forbidden by the RFC, but ideals are not always attainable attainable in
> practice.

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?

> That is why I would like to tag tests for liveDNS vs stubbed resolver.
> The stubbed resolver can test for the correct result when multiple
> identical records are in fact passed through.

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.

> Just because the DNS you are testing with happens to combine them,
> doesn't mean that in production you won't run into a cache that doesn't.

So what?

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

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

iD8DBQFGdDNkwL7PKlBZWjsRArvbAJ9KI6s14t5djbuCftacHM/iqtLhSACg2DY6
yWB8pLZZ+XsWcV9YB3oAPyk=
=1Py3
-----END PGP SIGNATURE-----

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

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. The
more unlikely, the more important to test for it. (More likely bugs will show
up in operation right away anyhow.) The fact that jSPF is unable to
test this scenario is a deficiency in the test setup. The stub
resolver has different deficiencies. No test setup is perfect.

> > Just because the DNS you are testing with happens to combine them,
> > doesn't mean that in production you won't run into a cache that doesn't.
>
> So what?

So you should produce the rfc mandated result given multiple identical records.

> > 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. The only difficulty is that a particular test setup
has trouble reproducing the multiple identical records scenario.

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. We can also allow both results in the test suite to reflect
that lack of consensus.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

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

-----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=1311533&user_secret=456ecacd
Powered by Listbox: http://www.listbox.com

Stuart D. Gathman ha scritto:
> 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. The
> more unlikely, the more important to test for it. (More likely bugs will show
> up in operation right away anyhow.) The fact that jSPF is unable to
> test this scenario is a deficiency in the test setup. The stub
> resolver has different deficiencies. No test setup is perfect.

Wait, the problem is not jSPF: in fact we simply found something weird
between DNS specification and SPF specification. We are already able to
test in a mock environment that specific behaviour but IMO it does not
make sense at all!

Why should we care that an implementation will return PermError on
multiple identical records when DNS caches are SUPPOSED to combine them?
I think that an implementation that treat multiple identical records as
a single record would be COMPLIANT because of DNS specification, and
being SPF based on DNS it MUST comply with what DNS states.

In fact we found an issue that probably you don't even tested in
implementation you declared "compliant" because we didn't limit
ourselves to mocked testing but we also created integration testing to
be sure we check also real resolution.

While I'm here I'd like to tell that current jSPF trunk perform SPF
lookups asynchronously and with a SEDA approach, so it should scale
better than other implementation. I still have to create tests for
throughput.

>>> Just because the DNS you are testing with happens to combine them,
>>> doesn't mean that in production you won't run into a cache that doesn't.
>> So what?
>
> So you should produce the rfc mandated result given multiple identical records.

IMO the spec should leverage the underlying DNS "transport", so it
should permit both result. if it was not an errata I would really prefer
to have the SPF spec to require different behaviour on multiple
identical records than multiple different records so to have a
predictable result for a given configuration, but the spec has already
been published and probably it is better to simply warn people about
that issue and let implementation to treat multiple identical records as
a single record (as many resolvers/caches will already do that).

>>> 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. The only difficulty is that a particular test setup
> has trouble reproducing the multiple identical records scenario.

It is not about test setups. Please try to understand that you can
publish multiple identical records but you can't really predict what the
SPF clients will receive. This is IMO really bad as the SPF spec
currently require different behavior given the resolvers/caches in the
transport layer.

> 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. We can also allow both results in the test suite to reflect
> that lack of consensus.

+1

Stefano

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

On Saturday 16 June 2007 17:23, Stuart D. Gathman wrote:

> 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. The
> more unlikely, the more important to test for it.

I think this is being pedantic beyond all logic. If someone want to do an
errata to say multiple <b> non-identical </b> records, I'm all for it. There
can be no harm in multiple records that are identical, it generates no
ambiguity.

Scott K

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

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

Scott Kitterman wrote:
> On Saturday 16 June 2007 17:23, Stuart D. Gathman wrote:
> > 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. The more unlikely, the more important to test for it.
>
> I think this is being pedantic beyond all logic. If someone want to do
> an errata to say multiple <b> non-identical </b> records, I'm all for
> it. There can be no harm in multiple records that are identical, it
> generates no ambiguity.

This _might_ have been the best resolution 2-3 years ago. However, now we
cannot do that anymore, as it would require implementations to check for
whether multiple records are identical or not. And grafting this onto RFC
4408 with a "SHOULD" (i.e. not strictly requiring the new behavior)
wouldn't solve the problem at hand.

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

iD8DBQFGdO55wL7PKlBZWjsRAlMVAJ4y94E98SW1k9iUdaHQS28AJx2MxQCdEUPg
f7NMLlXG2a51VAPm/ga+sfw=
=hvdh
-----END PGP SIGNATURE-----

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

On Sat, 16 Jun 2007, Julian Mehnle wrote:

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

That is irrelevant. What is relevant is that if you see multiple
records, whether identical or not, the 4408 result is PermError.
That 4408 compliance is what we are testing for. The 2181 behaviour
makes testing trickier when using live DNS, but otherwise is
unrelated.

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

They are both legal. But 4408 says that when your stub/resolver
gives you multiple identical records, the result is PermError.
The test suite tests for that very nicely in the case of a stub.
Live DNS is more difficult to test for this case due to 2181 5/1.

This is a testing problem, NOT a "what does the standard say" problem.
The reason to allow both results is not because the standard is
unclear, but because it is too difficult in practice to do the
test properly with live DNS. Live DNS testing is valuable because it
tests more of the whole system, so making some accomodations for it
is reasonable. Also, we promised to also support live DNS in the test
suite goals.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

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

On Sun, 17 Jun 2007, Stefano Bagnara wrote:

> It is not about test setups. Please try to understand that you can
> publish multiple identical records but you can't really predict what the
> SPF clients will receive. This is IMO really bad as the SPF spec
> currently require different behavior given the resolvers/caches in the
> transport layer.

You are absolutely correct. The 4408 mandated behaviour is essentially
impossible to test for with live DNS, and produces inconsistent results
depending on cache/resolver behaviour. This needs to be
fixed for v=spf3. We can't change 4408 and suddenly require implementations to
combine identical records. So the only reasonable course seems to be to allow
both results in the test suite - reflecting the inconsistent results seen in
the real worlds. It really isn't *that* bad a situation. Publishers
with multiple identical records *deserve* screwy results.

> > 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. We can also allow both results in the test suite to reflect
> > that lack of consensus.
>
> +1

+1 (I can vote for my own proposal?)

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

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

Stuart D. Gathman ha scritto:
> On Sat, 16 Jun 2007, Julian Mehnle wrote:
>
>>> 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.
>
> That is irrelevant. What is relevant is that if you see multiple
> records, whether identical or not, the 4408 result is PermError.
> That 4408 compliance is what we are testing for. The 2181 behaviour
> makes testing trickier when using live DNS, but otherwise is
> unrelated.

But rfc2181 let anyone working with DNS RRs to compact identical
records. So if I compact them just before applying SPF rules then I will
process the record instead of returning the PermError.

>> 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?
>
> They are both legal. But 4408 says that when your stub/resolver
> gives you multiple identical records, the result is PermError.
> The test suite tests for that very nicely in the case of a stub.
> Live DNS is more difficult to test for this case due to 2181 5/1.

As Julien already told, rfc2181 does IMO apply also to stup
implementations of a DNS resolver.
Why should you use a MUST in a specification when the application of
rfc2181 5/1 invalidate at all your MUST in case of multiple identical
records depending on the transport/implementation choices?
Your MUST will only work when no layer accepted to follow a SHOULD in
the dns specification.

Btw, I think I explained well enough the problem. I hope the SPF council
will analyze this and will report an official decision.

> This is a testing problem, NOT a "what does the standard say" problem.
> The reason to allow both results is not because the standard is
> unclear, but because it is too difficult in practice to do the
> test properly with live DNS. Live DNS testing is valuable because it
> tests more of the whole system, so making some accomodations for it
> is reasonable. Also, we promised to also support live DNS in the test
> suite goals.

In rfc2181 there is not "Live" concept, so I don't understand why you
keep referring "Live DNS testing".
Again, IMO the problem with the specification is that it requires a
behaviour that is unknown when you publish the duplicated records.
If you publish multiple different records every compliant implementation
will return PermError indipendently from the DNS implementations in the
chain, if you publish a single record every compliant implementation
will analyze the rule, if you publish multiple identical records you
don't know what a compliant implementation will return because you CAN'T
know what dns resolver/caches/server you have there.

It does not make sense at all: if you are simply telling that what is
wrote in the 4408 is like something said by God and cannot be wrong,
then ok, we can skip this discussion at all, otherwise it should be
considered that the rfc4408 may be inappropriate about this OR the
multiple result must be accepted because of rfc2181 5/1.

The intent of rfc2181 is to have multiple identical records to behave as
a single record. If you implement a specification on top of DNS you
cannot change the intents of the underlying transport and so IMO
considering multiple identical RRs as a single one is perfectly VALID
for rfc4408 because it is built on top of rfc2181 and we simply SHOULD
do that. To be strict the testsuite is simply testing that the
implementor did not follow a SHOULD in rfc2181, nothing more: it seems
to enforce a bad practice at all.

As Julian told the test should be changed to show multiple different
records.

Your explanation did not convice me at all: is like I'm building a
specification that uses TCP/IP as a transport and I add a requirement in
my specification to be followed when IP packet retransmission happens.
Packet retransmission should be hidden inside TCP/IP and protocols build
on top of it do never require different behaviour depending on something
that only belongs to TCP/IP. Whether identical RRs SHOULD be considered
as a single RRs and SHOULD be compacted it already clearly stated in
rfc2181, so anything different in rfc4408 is simply invalid.

Please read again rfc2181 5:
"It is meaningless for two records to ever have label, class, type and
data all equal"

It is MEANINGLESS means that you cannot add meaning to the existence of
multiple identical records. I'm sure rfc4408 does not suggest to ignore
the dns specification.

Stefano

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

Scott Kitterman ha scritto:
> On Saturday 16 June 2007 17:23, Stuart D. Gathman wrote:
>
>> 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. The
>> more unlikely, the more important to test for it.
>
> I think this is being pedantic beyond all logic. If someone want to do an
> errata to say multiple <b> non-identical </b> records, I'm all for it. There
> can be no harm in multiple records that are identical, it generates no
> ambiguity.
>
> Scott K

+1 The more I read the 2 spec the more I'm convinced that this is the
best solution.

Stefano

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

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

Stefano Bagnara wrote:
> As Julien already told, rfc2181 does IMO apply also to stup
> implementations of a DNS resolver.

Let me phrase it like this: from the DNS RFCs' PoV, there is no live DNS or
emulated DNS -- there's just DNS. Anyone who claims to implement DNS must
adhere to the same set of DNS RFCs.

> Again, IMO the problem with the specification is that it requires a
> behaviour that is unknown when you publish the duplicated records.

Well, the _real_ solution is for domain owners to NOT publish multiple
identical records. Then the problem won't occur in the first place.

Consequently, this is exactly what the test suite should do, or rather, not
do. I.e., it should not "publish" multiple identical records in the test
case that is actually supposed to test for RFC 4408 4.5/6.

> It does not make sense at all: if you are simply telling that what is
> wrote in the 4408 is like something said by God and cannot be wrong,
> then ok, we can skip this discussion at all, otherwise it should be
> considered that the rfc4408 may be inappropriate about this

RFC 4408 is not beyond criticism, however we cannot change it retroactively
and expect all the existing "v=spf1" implementations to follow suit (in
this case, they would have to newly implement recognition of multiple
identical RRs).

"v=spf1" is carved in stone. We have fought hard in the past to protect
its integrity. Of all the imaginable issues, this one certainly doesn't
warrant an exception.

> The intent of rfc2181 is to have multiple identical records to behave as
> a single record. If you implement a specification on top of DNS you
> cannot change the intents of the underlying transport and so IMO
> considering multiple identical RRs as a single one is perfectly VALID
> for rfc4408 because it is built on top of rfc2181 and we simply SHOULD
> do that.

Demanding that a DNS _application_ such as SPF combine multiple identical
RRs into a single RR would be highly unusual. Show me any other DNS app-
lication that specifies this.

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

iD8DBQFGdbD0wL7PKlBZWjsRAhuEAKCK4dxlAd9ImyEjHvmydVXSa/yi3gCdHMjV
5UaqU91Lj2nMTfvBVVMRfcw=
=17VG
-----END PGP SIGNATURE-----

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

On Sunday 17 June 2007 04:18, Julian Mehnle wrote:
> Scott Kitterman wrote:
> > On Saturday 16 June 2007 17:23, Stuart D. Gathman wrote:
> > > 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. The more unlikely, the more important to test for it.
> >
> > I think this is being pedantic beyond all logic. If someone want to do
> > an errata to say multiple <b> non-identical </b> records, I'm all for
> > it. There can be no harm in multiple records that are identical, it
> > generates no ambiguity.
>
> This _might_ have been the best resolution 2-3 years ago. However, now we
> cannot do that anymore, as it would require implementations to check for
> whether multiple records are identical or not. And grafting this onto RFC
> 4408 with a "SHOULD" (i.e. not strictly requiring the new behavior)
> wouldn't solve the problem at hand.
>
OK. How about MUST Permerror on multiple SPF records, except implementations
MAY treat multiple identical records as a single record?

Scott K

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

Julian Mehnle ha scritto:
> Stefano Bagnara wrote:
>> As Julien already told, rfc2181 does IMO apply also to stup
>> implementations of a DNS resolver.
>
> Let me phrase it like this: from the DNS RFCs' PoV, there is no live DNS or
> emulated DNS -- there's just DNS. Anyone who claims to implement DNS must
> adhere to the same set of DNS RFCs.

Right. Sorry for my bad english reporting your opinion..

>> Again, IMO the problem with the specification is that it requires a
>> behaviour that is unknown when you publish the duplicated records.
>
> Well, the _real_ solution is for domain owners to NOT publish multiple
> identical records. Then the problem won't occur in the first place.
>
> Consequently, this is exactly what the test suite should do, or rather, not
> do. I.e., it should not "publish" multiple identical records in the test
> case that is actually supposed to test for RFC 4408 4.5/6.

IMHO this is the minimum required change on SPF side. Right now the
testsuite does not take care of the DNS suggestion to compact identical
records and so the multispf* tests may fail even with a compliant
implementation (jSPF case). Switching to multiple different records will
keep testing the intent of RFC4408 4.5/6 without the assumption that the
DNS implementation is not following the "SHOULD compact" suggestion.

>> It does not make sense at all: if you are simply telling that what is
>> wrote in the 4408 is like something said by God and cannot be wrong,
>> then ok, we can skip this discussion at all, otherwise it should be
>> considered that the rfc4408 may be inappropriate about this
>
> RFC 4408 is not beyond criticism, however we cannot change it retroactively
> and expect all the existing "v=spf1" implementations to follow suit (in
> this case, they would have to newly implement recognition of multiple
> identical RRs).

It is not important at all if they apply or not apply the rule when they
receive multiple identical records: we already have unpredictable result
and the unpredictable result will remain. Unfortunately the testsuite
enforced a bad practice, IMO.

Maybe a better errata could be to specify "In case of multiple identical
records an implementation can either return PermError or parse the
record (see rfc2181 par 5): publishers SHOULD NOT publish multiple
records at all if they want predictable result".

I'm also curious to see how many of the current compliant
implementations do compact the results in the "live" environment: we
already know that there is a high probability that a dns cache/server in
the chain will compact them (bind based servers do that) and we also
know that some client library do the same. Dnsjava does this for sure,
and if I understood it also the standard C libresolve, based on bind
code, does the same: it would be interesting to check what libspf,
libspf2, pyspf, Mail-SPF do "for real".

Maybe the case of current implementations is already really different
from what you/we thought.

> "v=spf1" is carved in stone. We have fought hard in the past to protect
> its integrity. Of all the imaginable issues, this one certainly doesn't
> warrant an exception.

I think that at least an errata to warn people that multiple identical
records could be compacted by the underlying DNS transport and may lead
to unpredictable results (sometime PermError, sometimes elaborated)
would already help other implementors and publisher understanding the
special case.

I think the empty/explanation issues already created similar problems in
compliant implementations: fortunately this is all about parsing
"weird/wrong" records, so to change the required behaviour will only
affect results for not-diligent publishers that published something weird.

>> The intent of rfc2181 is to have multiple identical records to behave as
>> a single record. If you implement a specification on top of DNS you
>> cannot change the intents of the underlying transport and so IMO
>> considering multiple identical RRs as a single one is perfectly VALID
>> for rfc4408 because it is built on top of rfc2181 and we simply SHOULD
>> do that.
>
> Demanding that a DNS _application_ such as SPF combine multiple identical
> RRs into a single RR would be highly unusual. Show me any other DNS app-
> lication that specifies this.

IMHO the problem is not "to compact or not to compact". The problem is
requiring a PermError (a specific different action) on something that
the DNS spec tell us is not different from a single record.
To use your "question": show me any other DNS application that specifies
a different behaviour on multiple identical RRs ;-)

Stefano

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

Stuart D. Gathman ha scritto:
> 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.

Can you explain better this scenario? Shouldn't this be explained
somewhere in the rfc text or in a openspf website page, so we (not guru)
can be better aware of the corner cases ? :-)

Thank you,
Stefano

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

Julian Mehnle ha scritto:
> Stefano Bagnara wrote:
>> 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.
>
> This is an interesting approach. Can you package up this "mockable DNS
> server" and document its use? I could see linking to it from the official
> test suite webpage then.

Currently it is in the "tests" part of our sourcetree and I cannot
publish binaries from the test part.

Once I will be done with the compliance and we'll have published jSPF
1.0 final I will try to take care of publishing a standalone testing server.

To try some of the current implementations I would need hints on how to
call the current implementations from the command line, explaining them
to use a specific IP/PORT as their dns server and retrieve the results.

Stefano

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

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

Stefano Bagnara wrote:
> Maybe a better errata could be to specify "In case of multiple identical
> records an implementation can either return PermError or parse the
> record (see rfc2181 par 5):

Well, that would just make the inconclusive interpretation of the current
spec explicit. No harm done, but not much use either.

The problem lies with the test suite.

> publishers SHOULD NOT publish multiple records at all if they want
> predictable result".

But isn't that what RFC 2181 says already? I could see adding a warning
for domain owners (not implementors!) as an erratum, but it's probably of
little use to most: I haven't ever heard of someone having unexpected
problems due to multiple identical records published. The only case where
it seems to have happened is in the official test suite (you discovered
it). As for SPF implementors, it's not something they should be concerned
with.

> I'm also curious to see how many of the current compliant
> implementations do compact the results in the "live" environment: we
> already know that there is a high probability that a dns cache/server in
> the chain will compact them (bind based servers do that) and we also
> know that some client library do the same. Dnsjava does this for sure,
> and if I understood it also the standard C libresolve, based on bind
> code, does the same: it would be interesting to check what libspf,
> libspf2, pyspf, Mail-SPF do "for real".

Agreed. We could test it using your fake DNS server (as soon as you have
packaged it), for example.

> > Demanding that a DNS _application_ such as SPF combine multiple
> > identical RRs into a single RR would be highly unusual. Show me any
> > other DNS application that specifies this.
>
> IMHO the problem is not "to compact or not to compact". The problem is
> requiring a PermError (a specific different action) on something that
> the DNS spec tell us is not different from a single record.
> To use your "question": show me any other DNS application that specifies
> a different behaviour on multiple identical RRs ;-)

SMTP, MX records. Multiple identical RRs make a typical SMTP client
perform multiple lookups, not one. At least, RFC 2821 section 5 doesn't
specify any MX RR compaction.

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

iD8DBQFGdkhgwL7PKlBZWjsRAiVDAKCDa9Cp3lqYih0l2NxQ6EAnxhiF3gCgoxtv
MryjI2l/vf2MxXJv79JFDO0=
=6GKq
-----END PGP SIGNATURE-----

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

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

Scott Kitterman wrote:
> On Sunday 17 June 2007 04:18, Julian Mehnle wrote:
> > Scott Kitterman wrote:
> > > [...] If someone want to do an errata to say multiple <b>
> > > non-identical </b> records, I'm all for it. There can be no harm in
> > > multiple records that are identical, it generates no ambiguity.
> >
> > This _might_ have been the best resolution 2-3 years ago. However,
> > now we cannot do that anymore, as it would require implementations to
> > check for whether multiple records are identical or not. And grafting
> > this onto RFC 4408 with a "SHOULD" (i.e. not strictly requiring the
> > new behavior) wouldn't solve the problem at hand.
>
> OK. How about MUST Permerror on multiple SPF records, except
> implementations MAY treat multiple identical records as a single record?

I think we could do that.

But this would still just make the inconclusive interpretation of the spec
explicit, and leave the problem to be fixed in the test suite.

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

iD8DBQFGdkjfwL7PKlBZWjsRAmbUAKCcBP30ua0+kRGLZhb6o4GnhbPHQgCgp/bL
mvlep8E8rLjdDfq0i3GDUNM=
=L4Al
-----END PGP SIGNATURE-----

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

Julian Mehnle ha scritto:
> Stefano Bagnara wrote:
>> IMHO the problem is not "to compact or not to compact". The problem is
>> requiring a PermError (a specific different action) on something that
>> the DNS spec tell us is not different from a single record.
>> To use your "question": show me any other DNS application that specifies
>> a different behaviour on multiple identical RRs ;-)
>
> SMTP, MX records. Multiple identical RRs make a typical SMTP client
> perform multiple lookups, not one. At least, RFC 2821 section 5 doesn't
> specify any MX RR compaction.

Well, on SMTP you will find me prepared as I'm a developer of Apache
JAMES SMTP server :-)

rfc2821 DOES NOT add any specification related to multiple identical MX
RRs: it simply rely on what the underlying DNS implementation do, as it
is supposed to. The fact is that if you want to define your load
balancing the only way to make it working every time is to define
multiple MX pointing to *different* host names, having (if needed) some
host name to point to the same address (but not using multiple identical
IP for the same host or multiple identical MX names).

The important thing to be noticed is that SMTP does not add any
specification that will alter the final behavior in a critical way
depending on the underlying dns chain "compression" policy.

IMHO the whole thing is really not very important as publisher ar e not
supposed to publish multiple records at all (identical or different) and
we are only discussing how to improve and make more predictable the
corner case (for not compliant published records) handling.

So, if there is agreement that at least the testsuite is inappropriate,
please let's find a short way to this and let's change the duplicates to
be different :-)

Thank you,
Stefano

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

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

Stefano Bagnara wrote:
> Julian Mehnle ha scritto:
> > Stefano Bagnara wrote:
> > > IMHO the problem is not "to compact or not to compact". The problem
> > > is requiring a PermError (a specific different action) on something
> > > that the DNS spec tell us is not different from a single record.
> > > To use your "question": show me any other DNS application that
> > > specifies a different behaviour on multiple identical RRs ;-)
> >
> > SMTP, MX records. Multiple identical RRs make a typical SMTP client
> > perform multiple lookups, not one. At least, RFC 2821 section 5
> > doesn't specify any MX RR compaction.
>
> Well, on SMTP you will find me prepared as I'm a developer of Apache
> JAMES SMTP server :-)
>
> rfc2821 DOES NOT add any specification related to multiple identical MX
> RRs: it simply rely on what the underlying DNS implementation do, as it
> is supposed to.

Exactly. And if an SMTP client receives...

example.com. MX 10 mta.example.com.
example.com. MX 10 mta.example.com.

... then it will likely behave differently than if it had received just
_one_ of those records (i.e. it will try to connect to mta.example.com two
times if that host isn't reachable). RFC 2821 does NOT specify that such
identical records must be treated as a single one. So why should RFC
4408?

> The important thing to be noticed is that SMTP does not add any
> specification that will alter the final behavior in a critical way
> depending on the underlying dns chain "compression" policy.

That's true.

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

iD8DBQFGdmZhwL7PKlBZWjsRAuPPAKDXI/7P/ByaOqWPRJTzavAgunit2wCfQMZ+
7XShEq3fNy+QPN3W5DbtnfM=
=ZNT4
-----END PGP SIGNATURE-----

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

On Monday 18 June 2007 04:57, Julian Mehnle wrote:
> Scott Kitterman wrote:
> > On Sunday 17 June 2007 04:18, Julian Mehnle wrote:
> > > Scott Kitterman wrote:
> > > > [...] If someone want to do an errata to say multiple <b>
> > > > non-identical </b> records, I'm all for it. There can be no harm in
> > > > multiple records that are identical, it generates no ambiguity.
> > >
> > > This _might_ have been the best resolution 2-3 years ago. However,
> > > now we cannot do that anymore, as it would require implementations to
> > > check for whether multiple records are identical or not. And grafting
> > > this onto RFC 4408 with a "SHOULD" (i.e. not strictly requiring the
> > > new behavior) wouldn't solve the problem at hand.
> >
> > OK. How about MUST Permerror on multiple SPF records, except
> > implementations MAY treat multiple identical records as a single record?
>
> I think we could do that.
>
> But this would still just make the inconclusive interpretation of the spec
> explicit, and leave the problem to be fixed in the test suite.

Yes, but if we have an errata to allow this behavior then there's nothing to
argue about the test suite, it just needs to be updated. It is an
inconsistency, but given that DNS may compact the duplicate records to a
single record, the inconsistency already exists. This just makes it more
obvious.

Scott K

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

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

Scott Kitterman wrote:
> On Monday 18 June 2007 04:57, Julian Mehnle wrote:
> > Scott Kitterman wrote:
> > > How about MUST Permerror on multiple SPF records, except
> > > implementations MAY treat multiple identical records as a single
> > > record?
> >
> > I think we could do that.
> >
> > But this would still just make the inconclusive interpretation of the
> > spec explicit, and leave the problem to be fixed in the test suite.
>
> Yes, but if we have an errata to allow this behavior then there's
> nothing to argue about the test suite, it just needs to be updated. It
> is an inconsistency, but given that DNS may compact the duplicate
> records to a single record, the inconsistency already exists. This just
> makes it more obvious.

True, true. But I don't think we need to make an erratum for every
fuzziness of the spec. We have "clarified" fuzziness in the RFC via the
test suite before, without creating errata.

However, I still prefer to simply _sidestep_ the issue by applying the
proposed patch to the test suite instead of testing for RFC 2181 5/1 and
allowing for ambiguous results.

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

iD8DBQFGdns5wL7PKlBZWjsRArXrAJ0Z4UylxEuwgTl2S6v9+fVvBYqwKQCfYkEO
oXrzGYNzkvjyx61M3mhB25A=
=KV+M
-----END PGP SIGNATURE-----

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

Julian Mehnle ha scritto:
> Stefano Bagnara wrote:
>> Julian Mehnle ha scritto:
>>> Stefano Bagnara wrote:
>>>> IMHO the problem is not "to compact or not to compact". The problem
>>>> is requiring a PermError (a specific different action) on something
>>>> that the DNS spec tell us is not different from a single record.
>>>> To use your "question": show me any other DNS application that
>>>> specifies a different behaviour on multiple identical RRs ;-)
>>> SMTP, MX records. Multiple identical RRs make a typical SMTP client
>>> perform multiple lookups, not one. At least, RFC 2821 section 5
>>> doesn't specify any MX RR compaction.
>> Well, on SMTP you will find me prepared as I'm a developer of Apache
>> JAMES SMTP server :-)
>
>> rfc2821 DOES NOT add any specification related to multiple identical MX
>> RRs: it simply rely on what the underlying DNS implementation do, as it
>> is supposed to.
>
> Exactly. And if an SMTP client receives...
>
> example.com. MX 10 mta.example.com.
> example.com. MX 10 mta.example.com.
>
> ... then it will likely behave differently than if it had received just
> _one_ of those records (i.e. it will try to connect to mta.example.com two
> times if that host isn't reachable). RFC 2821 does NOT specify that such
> identical records must be treated as a single one. So why should RFC
> 4408?

There is IMO a big difference:

- The behaviour of an SMTP client does not change too much depending on
DNS consolidation: that mx server will be tried anyway, and the fact
that is tried one or multiple times already depends on implementation
details (e.g: the SMTP specification is already very relaxed about
interpretations of whether the use multihomed servers - multiple IN A
for the same MX host name - should be iterated or not, so I don't really
see this issue at the same level of the rfc4408 issue. Also how many
servers to check before giving up is left to the implementor)

- Instead in the case of rfc4408 the result is completely unpredictable:
if the dns chain consolidate the results then the SPF client will check
the SPF rule as valid, otherwise it will return a PermError.

Btw I think we can discuss similar interpretation for years with not so
useful results ;-) .. I think at least 2-3 guys here agree that the
testsuite should be updated and maybe some clarification text added to
the specification, let's work on this :-)

Stefano

>> The important thing to be noticed is that SMTP does not add any
>> specification that will alter the final behavior in a critical way
>> depending on the underlying dns chain "compression" policy.
>
> That's true.
>

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



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

On Monday 18 June 2007 08:31, Julian Mehnle wrote:
> Scott Kitterman wrote:
> > On Monday 18 June 2007 04:57, Julian Mehnle wrote:
> > > Scott Kitterman wrote:
> > > > How about MUST Permerror on multiple SPF records, except
> > > > implementations MAY treat multiple identical records as a single
> > > > record?
> > >
> > > I think we could do that.
> > >
> > > But this would still just make the inconclusive interpretation of the
> > > spec explicit, and leave the problem to be fixed in the test suite.
> >
> > Yes, but if we have an errata to allow this behavior then there's
> > nothing to argue about the test suite, it just needs to be updated. It
> > is an inconsistency, but given that DNS may compact the duplicate
> > records to a single record, the inconsistency already exists. This just
> > makes it more obvious.
>
> True, true. But I don't think we need to make an erratum for every
> fuzziness of the spec. We have "clarified" fuzziness in the RFC via the
> test suite before, without creating errata.
>
> However, I still prefer to simply _sidestep_ the issue by applying the
> proposed patch to the test suite instead of testing for RFC 2181 5/1 and
> allowing for ambiguous results.

I'm good with that too. IMO the only reason to go to the trouble of an
erratum would be to justify the test suite change if required. Personally, I
don't think it's required.

Scott K

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

Scott Kitterman ha scritto:
> On Monday 18 June 2007 08:31, Julian Mehnle wrote:
>> Scott Kitterman wrote:
>>> On Monday 18 June 2007 04:57, Julian Mehnle wrote:
>>>> Scott Kitterman wrote:
>>>>> How about MUST Permerror on multiple SPF records, except
>>>>> implementations MAY treat multiple identical records as a single
>>>>> record?
>>>> I think we could do that.
>>>>
>>>> But this would still just make the inconclusive interpretation of the
>>>> spec explicit, and leave the problem to be fixed in the test suite.
>>> Yes, but if we have an errata to allow this behavior then there's
>>> nothing to argue about the test suite, it just needs to be updated. It
>>> is an inconsistency, but given that DNS may compact the duplicate
>>> records to a single record, the inconsistency already exists. This just
>>> makes it more obvious.
>> True, true. But I don't think we need to make an erratum for every
>> fuzziness of the spec. We have "clarified" fuzziness in the RFC via the
>> test suite before, without creating errata.
>>
>> However, I still prefer to simply _sidestep_ the issue by applying the
>> proposed patch to the test suite instead of testing for RFC 2181 5/1 and
>> allowing for ambiguous results.
>
> I'm good with that too. IMO the only reason to go to the trouble of an
> erratum would be to justify the test suite change if required. Personally, I
> don't think it's required.
>
> Scott K

40 days after, I see the Errata page is unchanged and the test suite in
SVN is unchanged: is there anything I can do for something to become real?

I thought there was an agreement on patching the test suite by using
multiple *different* records instead of multiple identical records.

Stefano

-------------------------------------------
-----------------------------------------------------------------------
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?member_id=1311533&id_secret=26388368-d9c2b1
Powered by Listbox: http://www.listbox.com

On Sun, 29 Jul 2007, Stefano Bagnara wrote:

> 40 days after, I see the Errata page is unchanged and the test suite in
> SVN is unchanged: is there anything I can do for something to become real?

I thought it was done because of the announcement. I will add the extra
result tonight or tomorrow morning. I will also ensure there is a
multiple different records test.

> I thought there was an agreement on patching the test suite by using
> multiple *different* records instead of multiple identical records.

No, the agreement was to allow multiple results for multiple same
records. The library may still conceivably be presented with multiple same
records and must respond correctly in that case - but the test suite
can't cause that situation when using live DNS. In addition, some
think the spec is wrong, and you should be allowed to combine identical
records - but that again is handled by allowing multiple results.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------------------------------------------
-----------------------------------------------------------------------
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?member_id=1311533&id_secret=26393273-3b12e7
Powered by Listbox: http://www.listbox.com

On Sun, 29 Jul 2007, Stuart D. Gathman wrote:

> > I thought there was an agreement on patching the test suite by using
> > multiple *different* records instead of multiple identical records.
>
> No, the agreement was to allow multiple results for multiple same
> records. The library may still conceivably be presented with multiple same
> records and must respond correctly in that case - but the test suite
> can't cause that situation when using live DNS. In addition, some
> think the spec is wrong, and you should be allowed to combine identical
> records - but that again is handled by allowing multiple results.

I modified multispf1 to allow a result consistent with combining
identical records. I modified multispf2 to make the 2 SPF records
different. New development version is 90.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------------------------------------------
-----------------------------------------------------------------------
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?member_id=1311533&id_secret=26434366-a7d208
Powered by Listbox: http://www.listbox.com

Stuart D. Gathman ha scritto:
> On Sun, 29 Jul 2007, Stuart D. Gathman wrote:
>
>>> I thought there was an agreement on patching the test suite by using
>>> multiple *different* records instead of multiple identical records.
>> No, the agreement was to allow multiple results for multiple same
>> records. The library may still conceivably be presented with multiple same
>> records and must respond correctly in that case - but the test suite
>> can't cause that situation when using live DNS. In addition, some
>> think the spec is wrong, and you should be allowed to combine identical
>> records - but that again is handled by allowing multiple results.
>
> I modified multispf1 to allow a result consistent with combining
> identical records. I modified multispf2 to make the 2 SPF records
> different. New development version is 90.

It works.

SPF Test Suite 90 now seems to be compliant with jSPF ... and viceversa ;-)

Thank you,
Stefano

-------------------------------------------
-----------------------------------------------------------------------
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?member_id=1311533&id_secret=26451880-67689f
Powered by Listbox: http://www.listbox.com