Mailing List Archive

Local vs global namespace for SPF testcases
testcase DNS data must be sanitized. This is simpler if each test
case has its own self-contained DNS data.

However, if all test cases share a common DNS dataset, then it is
simpler to load that data into a local DNS server for testing SPF
with an actual resolver. With self-contained data, the local DNS server
would have to be reloaded for each testcase.

With self-contained DNS data, we can post testcases to the mailing list,
without having to reference a particular version of the global DNS test
data.

Is there a way to have the best of both worlds?

--
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/?listname=spf-devel@v2.listbox.com
Re: Local vs global namespace for SPF testcases [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stuart D. Gathman wrote:
> testcase DNS data must be sanitized. This is simpler if each test
> case has its own self-contained DNS data.
>
> However, if all test cases share a common DNS dataset, then it is
> simpler to load that data into a local DNS server for testing SPF
> with an actual resolver. With self-contained data, the local DNS server
> would have to be reloaded for each testcase.

I'm not even convinced that there is a real benefit in having test data in
(global or local) DNS. Could someone convince me, please?

> With self-contained DNS data, we can post testcases to the mailing list,
> without having to reference a particular version of the global DNS test
> data.
>
> Is there a way to have the best of both worlds?

Sure. Just define a domain name translation function that bijectively
translates between (test-id, test-local-domain-name) and (test-id, global-
domain-name). E.g.:

[test-id = foo]
example.com. IN SPF "v=spf1 -all"

<-->

example.com.foo.spfv1.tests.openspf.org. IN SPF "v=spf1 -all"

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

iD8DBQFEowbqwL7PKlBZWjsRAo1uAJ0beHnZZGZJVao0n2e1VLNqK+MhWwCfV4Zs
vifDBEipU8titdOmrQLd9eY=
=5SaB
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
Re: Re: Local vs global namespace for SPF testcases [ In reply to ]
On Wed, 28 Jun 2006, Julian Mehnle wrote:

> I'm not even convinced that there is a real benefit in having test data in
> (global or local) DNS. Could someone convince me, please?

While not useful for most debugging, it is an end to end test.
What if there is a bug in your DNS resolver that affects SPF results?
Using a stub resolver and memory database if fast and repeatable, but
not end to end. Of course, the ultimate end to end test runs from
your MTA.

> > With self-contained DNS data, we can post testcases to the mailing list,
> > without having to reference a particular version of the global DNS test
> > data.
> >
> > Is there a way to have the best of both worlds?
>
> Sure. Just define a domain name translation function that bijectively
> translates between (test-id, test-local-domain-name) and (test-id, global-
> domain-name). E.g.:
>
> [test-id = foo]
> example.com. IN SPF "v=spf1 -all"
>
> <-->
>
> example.com.foo.spfv1.tests.openspf.org. IN SPF "v=spf1 -all"

Good idea. Not *completely* end to end (have to interpolate simple translation
function), but pretty close. I consider that problem solved.

--
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/?listname=spf-devel@v2.listbox.com