Mailing List Archive

In <courier.404358B8.000005FB@mail.farside.org.uk> "Malcolm Rowe" <malcolm-spf@farside.org.uk> writes:

> * The SPF testsuite, which seems to be included in Mail::SPF::Query -
> * is it also available standalone?

See http://www.midwestcs.com/spf/tests

Actually, the tests in libspf-alt are slightly better than these right
now, and the tests in the upcoming v0.2 version are even slightly more
complete. V0.2 of libspf-alt is mainly portability support. I now
use include a configure script and have rearranged the source into a
directory tree.


> * libspf-alt, at http://www.midwestcs.com/spf/libspf-alt/. I may well
> * end up stealing some or more of libspf-alt, though I can't use it
> * directly, because (among other things) I'll need to use Courier's
> * internal DNS functions.

One of the main design goals of libspf-alt was to create an abstract
interface layer between DNS and the rest of the library.

I suspect that you would be easily able to create something very
similar to spf_dns_resolv.c using Courier's DNS functions instead of
the resolver. If you go this way, please send me the spf_dns_courier
file and I'll include it in future releases of libspf-alt.


> Is there anything else I should be aware of?

Ask questions. Join the #libspf channel on irc.pobox.com.


-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h

James Couzens wrote:

>>Is there anything else I should be aware of?
> I encourage you to take notice of: http://libspf.org
>
> Reasons:
>
> #1 - half the size (codebase) of libspf-alt
> #2 - includes API demonstration through included Qmail and Sendmail
> patches to add native support to those MTA's
> #3 - C89/C99 ANSI compliant
> #4 - libspf is more mature and much more widely tested
> #5 - this is PRECISELY what libspf was written for.
> #6 - includes test suite and spfquery binary C tools
> #7 - code is heavily commented and memory leak free
>
> I have started a Courier patch but have yet to finish it, having you
> take the time to write it would be excellent!

Sorry, I should have mentioned libspf - I did take a look at it.
Unfortunately, the license for libspf is incompatible with Courier's
license (namely, the GPL), so a Courier+libspf package wouldn't be
distributable.

Regards,
Malcolm


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h

Malcolm Rowe <malcolm-spf@farside.org.uk> [2004-03-01/19:37]:
> Unfortunately, the license for libspf is incompatible with Courier's
> license (namely, the GPL), so a Courier+libspf package wouldn't be
> distributable.

IANAL, but if that were true, Linux would not be distributable.
According to the GNU licenses list [1], the revised BSD license is
compatible with the GPL, which means you can happily combine GPL and BSD
modules/libraries into a single package. Of course, you would have to
release your modifications to libspf itself under the BSD style libspf
license, but the code that uses libspf could be GPL just fine.

Cheers,
Dan

[1] http://www.gnu.org/philosophy/license-list.html

--
Daniel Roethlisberger <daniel@roe.ch>
GnuPG key ID 0x804A06B1 (DSA/ElGamal)

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ï#ÄÏÉæGã!'Rzš´ˆ»£‡Æ~3com

Daniel Roethlisberger wrote:
>>Unfortunately, the license for libspf is incompatible with Courier's
>>license (namely, the GPL), so a Courier+libspf package wouldn't be
>>distributable.
> According to the GNU licenses list [1], the revised BSD license is
> compatible with the GPL, [...]

Oh, my mistake. I looked at the license terms and figured that it was
under the original BSD license (the one that FSF described as having the
'obnoxious BSD advertising clause'), or one substantially similar. I'm
not that familiar with the BSD licenses, so I didn't recognise it
immediately.

You're right, though, it's the modified BSD license. Maybe I'll take
another look.

Regards,
Malcolm

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h

wayne wrote:

>> [...] I'll need to use Courier's internal DNS functions.
> One of the main design goals of libspf-alt was to create an abstract
> interface layer between DNS and the rest of the library.
>
> I suspect that you would be easily able to create something very
> similar to spf_dns_resolv.c using Courier's DNS functions instead of
> the resolver. If you go this way, please send me the spf_dns_courier
> file and I'll include it in future releases of libspf-alt.

That's interesting, I hadn't realised that libspf-alt was configurable
like that. But isn't that the wrong way to go about it? Surely Courier
should contain the 'glue' code that interfaces with libspf-alt, so that
the dependency is 'Courier upon libspf-alt', not both ways?

What I'd ideally like is to be able to take a copy of libspf-alt and
include it in a directory off the main Courier tree, include the glue
code in Courier (in other words, the bits that tell libspf-alt how to do
DNS queries using Courier), and compile the whole thing together - then
just update the libspf-alt directory with the latest version periodically.

I don't need to include libspf-alt's DNS resolver, so I'd like some way
to not have to compile it in (a NO_DEFAULT_DNS macro or similar),
otherwise I'm still dependant on external (DNS resolver) libraries.
Ideally, I'd like libspf-alt not to have any requirements other than 'a
working C compiler and (g)libc', so that including a copy in the main
Courier tree won't run the risk of breaking anyone else.

This isn't how I was planning to do it, but it makes a lot more sense in
the long term. I've asked Sam Varshavchik (Courier's maintainer) whether
he'd be ok with a solution that included third-party code in Courier's tree.

Regards,
Malcolm

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h

In <40444887.6080005@farside.org.uk> Malcolm Rowe <malcolm-spf@farside.org.uk> writes:

> wayne wrote:
>
>>> [...] I'll need to use Courier's internal DNS functions.
>> One of the main design goals of libspf-alt was to create an abstract
>> interface layer between DNS and the rest of the library.
>> I suspect that you would be easily able to create something very
>> similar to spf_dns_resolv.c using Courier's DNS functions instead of
>> the resolver. If you go this way, please send me the spf_dns_courier
>> file and I'll include it in future releases of libspf-alt.
>
> That's interesting, I hadn't realised that libspf-alt was configurable
> like that.

Yep, I saw a lot of requests for doing different things with DNS, so I
figured it should be configurable.

> But isn't that the wrong way to go about it? Surely Courier
> should contain the 'glue' code that interfaces with libspf-alt, so
> that the dependency is 'Courier upon libspf-alt', not both ways?

Yeah, you have a point there. If you sent me a spf_dns_courier.c
file, I would include it in libspf-alt, but I probably wouldn't
compile it in by default. I would try and keep it updated with
changes to the internals of libspf-alt, but I would need your help to
make sure it was tested.

On a somewhat related note, like the perl Mail::SPF and libspf, I am
including the code/patches needed for various MTAs to use SPF. Not
only would I really appreciate the spf_dns_courier file, but I would
like to include the rest of the patches to Courier too.


> What I'd ideally like is to be able to take a copy of libspf-alt and
> include it in a directory off the main Courier tree, include the glue
> code in Courier (in other words, the bits that tell libspf-alt how to
> do DNS queries using Courier), and compile the whole thing together -
> then just update the libspf-alt directory with the latest version
> periodically.

That would certainly be a valid way of doing things. Writing a DNS
layer for libspf-alt requires you to use the libspf-alt "internal" API
instead of the normal public API. This isn't a big deal, but it does
mean that you will have to include a couple of new include files and
that the courier DNS layer will likely have to be recompiled for new
versions of libspf-alt instead of just installing a new shared
library. Libspf-alt DNS layers do not need to be put into the
library, they can be included in your own source tree.


> I don't need to include libspf-alt's DNS resolver, so I'd like some
> way to not have to compile it in (a NO_DEFAULT_DNS macro or similar),

If you don't use the spf_dns_resolv DNS layer, it won't be linked in
to the resulting program. If you really don't want to even compile
it, you can take it out of the Makefile. The libspf-alt resolver
layer is very optional for this very reason.


> This isn't how I was planning to do it, but it makes a lot more sense
> in the long term. I've asked Sam Varshavchik (Courier's maintainer)
> whether he'd be ok with a solution that included third-party code in
> Courier's tree.

Another possibility is to use the spfd daemon and simply communicate
with it via a socket. This is how SPF support for Exim is currently
done. Exim requires only a configuration file change.


-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h