Re: Upcoming new test-suite release
Julian Mehnle <[email protected]> Wed, 20 Aug 2008 09:06:58 +0000
| Newsgroups | gmane.mail.spam.spf.devel |
|---|---|
| Message-ID | <[email protected]> |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stefano Bagnara wrote: > Julian Mehnle ha scritto: > > Stefano Bagnara wrote: > > > The jSPF tester have the ability to load a zone configuration from > > > the yaml file, set up a "fake" dsn server on a given port, read > > > tests, run the spf checker and check the results. > > > > > > One issue I've found when trying our tester against other > > > implementations is that it is not easy to tell other implementations > > > to use a specific dns server/port for the resolution. > > > > FWIW, it's all but trivial with Mail::SPF. One can specify a custom > > DNS resolver object, e.g., a Net::DNS::Resolver object configured to > > always use a specific resolving server. > > I'm not a perl programmer, so I won't do this. A configuration option > to override the dns servers would do the trick. Actually, I'd rather have the online version of the test suite driver append a given zone name to every lookup performed, e.g., 2008_08.rfc4408.test-suite.openspf.org. That way you wouldn't have to specify a custom resolver server. That zone can then be delegated to your fake DNS server. > > Besides, running an SPF implementations self-tests could be made (by > > authors) as easy as `make test`. It even almost works with Mail::SPF > > -- you just have to run `perl Makefile.PL` beforehand. > > The difference between this test and "selftests" is big, IMHO. > Most "self-tests" I've seen around don't actually run a real UDP/TCP > dns query, but they mock the whole resolution mechanism at one or > another layer. Otherwise we could have a "selftest" returning "ok" for > any test without checking the real result. I don't see the difference as being all that big, given that the test suite drivers are probably rather trivial, but I certainly don't object to have SPF implementations tested against live DNS. If you're willing to help with setting this up, or even lead the effort, all the better! > BTW I don't care if you will or won't use the jSPF tester once we'll > publish it, but I'm a bit annoyed that OpenSPF page keep saying that > the only compliant implementations are pyspf 2 and Mail::SPF only > because OpenSPF members wrote that while jSPF has an "the jSPF library > is currently being evaluated by the project for RFC 4408 compliance" > since years. At the end of 2006 jSPF was listed as "The jSPF library is > also reported to pass all tests in the test suite, however this has not > yet been officially confirmed" and then on 2006-12-10 you removed the > whole sentence. On 2007-02-01 then the "currently being evaluated" has > been written there... 18 months passed since that... > > IMHO it is bad for OpenSPF to fail to tell how implementations can be > listed between compliant implementation and ignore anyone but your own > implementations. As Stuart said, this isn't in any way due to a desire for self-promotion. The reason that the website still says "The jSPF library is currently being evaluated by the project for RFC 4408 compliance" simply is that when I tried to run the (offline) test-suite against jSPF over a year ago, it was very complicated to get it to work for someone who isn't an experienced Java/Maven developer, and that the generated output was practically unreadable, and no one else capable of editing the website has since tried checking out jSPF's compliance. I admit that it was my fault not to have announced that I had given up on trying to get useful output from my jSPF test-suite runs, and hadn't asked that someone else give it a try. So please don't be mad, but let's now try to get this resolved instead. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkir3rIACgkQwL7PKlBZWjt+hQCgvaUqjODGqBHoBGCj6DbWJIzo qQUAn1lV0LJR/sbXPowmNdrKSfu1YRG1 =jZrW -----END PGP SIGNATURE-----