Mailing List Archive

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