Mailing List Archive: SPF: Devel

Live-DNS testing infrastructure (was: Implementation certification procedure)

Index | Next | Previous | View Threaded

julian at mehnle

Aug 20, 2008, 4:49 AM

Post #1 of 9 (2667 views)
Permalink

Live-DNS testing infrastructure (was: Implementation certification procedure)

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

scott at kitterman

Aug 20, 2008, 5:09 AM

Post #2 of 9 (2567 views)
Permalink

Re: Live-DNS testing infrastructure (was: Implementation certification procedure) [In reply to]

On Wed, 20 Aug 2008 11:49:02 +0000 Julian Mehnle <julian[at]mehnle.net> wrote:
>Stefano Bagnara wrote:
>> Julian Mehnle ha scritto:
...
>> > > 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.

Age wise this is correct, but pyspf at least provides spfquery, but not
spfd.

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

Currently I think pyspf is supporting libspf2, Mail::SPF::Query, and
Mail::SPF style spfquery. Please let's not add more.

Scott K

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

stuart at bmsi

Aug 20, 2008, 6:15 AM

Post #3 of 9 (2579 views)
Permalink

Re: Live-DNS testing infrastructure (was: Implementation certification procedure) [In reply to]

On Wed, 20 Aug 2008, Scott Kitterman wrote:

> >Not any less standard than the spfquery protocol. The 'spfd' program is
> >about as old as the 'spfquery' one.
>
> Age wise this is correct, but pyspf at least provides spfquery, but not
> spfd.

It would be nearly trivial to implement if the protocol is described in detail.

--
Stuart D. Gathman <stuart[at]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.

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

apache at bago

Aug 20, 2008, 6:15 AM

Post #4 of 9 (2567 views)
Permalink

Re: Live-DNS testing infrastructure [In reply to]

Scott Kitterman ha scritto:
> Currently I think pyspf is supporting libspf2, Mail::SPF::Query, and
> Mail::SPF style spfquery. Please let's not add more.

I agree. Can you give me fast pointers to that styles? (urls/examples)
So I can take care of using one or all of them in jSPF too.

Stefano

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

julian at mehnle

Aug 20, 2008, 7:15 AM

Post #5 of 9 (2564 views)
Permalink

Re: Live-DNS testing infrastructure [In reply to]

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

Scott Kitterman wrote:
> Julian Mehnle wrote:
> > Stefano Bagnara wrote:
> > > 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.
>
> Currently I think pyspf is supporting libspf2, Mail::SPF::Query, and
> Mail::SPF style spfquery. Please let's not add more.

Not add more, but agree on a standard and then document it.

As far as spfd's interface is concerned, which is probably the best
solution for an implementation-independent test harness interface,
there's really only that of the original spfd that was shipped with
Mail::SPF::Query and libspf2 (I think they behave identically), and the
one shipped with Mail::SPF. The only difference between the former and
the latter is the naming of the request/response fields as well as the
naming of the result codes ("unknown" vs. "permerror", "error" vs.
"temperror"):

http://search.cpan.org/dist/Mail-SPF/sbin/spfd#COMPATIBILITY

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

iEYEARECAAYFAkisJusACgkQwL7PKlBZWjtbZACfaL3iXMTm06U6lS2xscMFbdIL
8yYAoL1K61v7x5cAGq7JWSSSFVep2GLT
=yGiT
-----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

scott at kitterman

Aug 20, 2008, 7:41 AM

Post #6 of 9 (2560 views)
Permalink

Re: Live-DNS testing infrastructure [In reply to]

On Wednesday 20 August 2008 09:15, Stefano Bagnara wrote:
> Scott Kitterman ha scritto:
> > Currently I think pyspf is supporting libspf2, Mail::SPF::Query, and
> > Mail::SPF style spfquery. Please let's not add more.
>
> I agree. Can you give me fast pointers to that styles? (urls/examples)
> So I can take care of using one or all of them in jSPF too.

http://pymilter.cvs.sourceforge.net/pymilter/pyspf/README?revision=1.4.2.3&view=markup&pathrev=pyspf-2_0-branch

is the current pyspf 2.0.5 README. It includes a description of the supported
spfquery options. I don't recall for certain (now that I look at it again)
if this includes Julian's Mail::SPF approach or not. I know it covers
libspf2 and Mail::SPF::Query.

Scott K

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

apache at bago

Aug 25, 2008, 4:43 AM

Post #7 of 9 (2554 views)
Permalink

Re: Live-DNS testing infrastructure [In reply to]

Julian Mehnle ha scritto:
> -----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.

This would require an option to "mock" any dns query by appending
".<#-of-scenario>.2008_08.rfc4408.test.openspf.org" to the queried name.

I would prefer the test suite to already use the right names.

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

While we wait to see if anyone offer this, I'd like to know if any of
the implementors having a command line interface plan to add support to
specify a "custom dns server" or not. If no one adds such an option it
does not make any sense for me to release a tool and document it if the
only tested library is jSPF that is already tested programmatically by
the same code.

So, if anyone is interested I expect them to add a new option (let's say
-s/--server ip[:port]) to their command line.

Once/If I'll see implementations supporting this I'll complete the
command line tester.

Stefano

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

stuart at bmsi

Aug 25, 2008, 8:10 AM

Post #8 of 9 (2549 views)
Permalink

Re: Live-DNS testing infrastructure [In reply to]

On Mon, 25 Aug 2008, Stefano Bagnara wrote:

> So, if anyone is interested I expect them to add a new option (let's say
> -s/--server ip[:port]) to their command line.

I will be adding this to pyspf. I'll post here when I get to it. It
should be trivial, since pydns already has the options. However, pydns
reads /etc/resolv.conf to load a list of nameservers. Do we really
need a command line option? Or can pydns support a ':port' syntax for
the nameservers in /etc/resolv.conf ? A command line option would then
conflict with /etc/resolv.conf, and I guess would take precedence, or
else the command line option would insert a nameserver before any
/etc/resolv.conf nameservers.

--
Stuart D. Gathman <stuart[at]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.

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

apache at bago

Aug 25, 2008, 8:28 AM

Post #9 of 9 (2537 views)
Permalink

Re: Live-DNS testing infrastructure [In reply to]

Stuart D. Gathman ha scritto:
> On Mon, 25 Aug 2008, Stefano Bagnara wrote:
>
>> So, if anyone is interested I expect them to add a new option (let's say
>> -s/--server ip[:port]) to their command line.
>
> I will be adding this to pyspf. I'll post here when I get to it. It
> should be trivial, since pydns already has the options. However, pydns
> reads /etc/resolv.conf to load a list of nameservers. Do we really
> need a command line option? Or can pydns support a ':port' syntax for
> the nameservers in /etc/resolv.conf ? A command line option would then
> conflict with /etc/resolv.conf, and I guess would take precedence, or
> else the command line option would insert a nameserver before any
> /etc/resolv.conf nameservers.

This is up to you. I'd say that a command line parameter should use the
server I tell it to use and ignore /etc/resolv.conf at all.

It's the same for dig, host, nslookup commands. If you don't specify a
server they use the OS default, otherwise they query the server you
specified.

Stefano

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

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com