-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Stefano Bagnara wrote:
> Julian Mehnle ha scritto:
> > Can we instead agree instead on having a public DNS zone delegated to
> > your server and have it serve test records from there? That seems
> > cleaner to me than forcing implementations to use a specific resolver
> > server.
>
> No. The Yaml tests do not share the same zone. In fact every single
> yaml test declare its own zone (zonedata:) and I reconfigure the live
> tester and empty the caches at each test to make it work.
>
> If you make sure that the "zonedata:" from the rfc4408 can be merged in
> a single zonedata without conflicts then we can use this way.
That's certainly possible. Just number the scenarios sequentially and
construct names like this:
<name-in-zonedata>.<#-of-scenario>.2008_08.rfc4408.test.openspf.org
DNS names are unique within each scenario.
> In this case maybe you should rename the "example.com" in the testsuite
> to "testsuite.openspf.org" and then have that ptr pointing to some host
> where we run the live zone...
I don't think such a PTR-wise redirection is going to work. It will have
to be a proper zone delegation.
> not sure how feasible it is (I'm not ready to host a public service for
> this, I can manage if someone offer a box).
Can anyone reading this host a nameserver for this?
> > > Using the "commandline interface" is the only way I found to test
> > > different implementations using a single tester.
> >
> > Or you could use the spfd interface: pipe test data into STDIN, get
> > results from STDOUT. See
> > http://search.cpan.org/dist/Mail-SPF/sbin/spfd
> > for a good documentation of that interface. (spfd uses a TCP or UNIX
> > socket, but you could just as well implement the interface using a
> > pipe.)
>
> Interesting! How standard/used is this protocol?
Not any less standard than the spfquery protocol. The 'spfd' program is
about as old as the 'spfquery' one.
> Wouldn't it worth to publish command line conventions and spfd
> "protocols" in the OpenSPF website so that implementations can easily
> see what are the "suggested" interfaces?
Yes. It's just an issue of finding the time to do it. I'll try to do it
since I am the one who is most familiar with the original spfd/spfquery
interfaces (other than Meng, who is busy with other stuff nowadays) as
well as the thought-through-anew ones in Mail::SPF's versions of the
tools.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkisBK4ACgkQwL7PKlBZWjskLACgleW1eVBOEhj7YSbXS33CT22Y
HwQAoKP8pcPqyTyNXvm9kF4ES7KRLJq+
=AYvF
-----END PGP SIGNATURE-----
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/1007/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1007/
Powered by Listbox: http://www.listbox.com
Hash: SHA1
Stefano Bagnara wrote:
> Julian Mehnle ha scritto:
> > Can we instead agree instead on having a public DNS zone delegated to
> > your server and have it serve test records from there? That seems
> > cleaner to me than forcing implementations to use a specific resolver
> > server.
>
> No. The Yaml tests do not share the same zone. In fact every single
> yaml test declare its own zone (zonedata:) and I reconfigure the live
> tester and empty the caches at each test to make it work.
>
> If you make sure that the "zonedata:" from the rfc4408 can be merged in
> a single zonedata without conflicts then we can use this way.
That's certainly possible. Just number the scenarios sequentially and
construct names like this:
<name-in-zonedata>.<#-of-scenario>.2008_08.rfc4408.test.openspf.org
DNS names are unique within each scenario.
> In this case maybe you should rename the "example.com" in the testsuite
> to "testsuite.openspf.org" and then have that ptr pointing to some host
> where we run the live zone...
I don't think such a PTR-wise redirection is going to work. It will have
to be a proper zone delegation.
> not sure how feasible it is (I'm not ready to host a public service for
> this, I can manage if someone offer a box).
Can anyone reading this host a nameserver for this?
> > > Using the "commandline interface" is the only way I found to test
> > > different implementations using a single tester.
> >
> > Or you could use the spfd interface: pipe test data into STDIN, get
> > results from STDOUT. See
> > http://search.cpan.org/dist/Mail-SPF/sbin/spfd
> > for a good documentation of that interface. (spfd uses a TCP or UNIX
> > socket, but you could just as well implement the interface using a
> > pipe.)
>
> Interesting! How standard/used is this protocol?
Not any less standard than the spfquery protocol. The 'spfd' program is
about as old as the 'spfquery' one.
> Wouldn't it worth to publish command line conventions and spfd
> "protocols" in the OpenSPF website so that implementations can easily
> see what are the "suggested" interfaces?
Yes. It's just an issue of finding the time to do it. I'll try to do it
since I am the one who is most familiar with the original spfd/spfquery
interfaces (other than Meng, who is busy with other stuff nowadays) as
well as the thought-through-anew ones in Mail::SPF's versions of the
tools.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkisBK4ACgkQwL7PKlBZWjskLACgleW1eVBOEhj7YSbXS33CT22Y
HwQAoKP8pcPqyTyNXvm9kF4ES7KRLJq+
=AYvF
-----END PGP SIGNATURE-----
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/1007/=now
RSS Feed: https://www.listbox.com/member/archive/rss/1007/
Powered by Listbox: http://www.listbox.com