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