Mailing List Archive

>-----Original Message-----
>From: owner-spf-devel@v2.listbox.com
>[mailto:owner-spf-devel@v2.listbox.com]On Behalf Of Per Jessen
>Sent: Wednesday, June 22, 2005 6:27 AM
>To: spf-devel@v2.listbox.com
>Subject: [spf-devel] libspf or libspf2 ?
>
>
>Gents,
>
>I'm investigating writing a high-volume postfix policy daemon for
>SPF. So far I have not come
>across anything like that already out there. There are couple of
>daemons written in perl -
>which doesn't rhyme very well with high-volume.
>
>The next step appears to be choosing between libspf and libspf2.
>This mailing list seems pretty
>dead, and I can't find a mailinglist for libspf - which in both
>cases isn't very promising wrt
>support etc.
>
>So which library do I pick?
>
>
>
>/Per Jessen, Zürich
>
The author of libspf2 is more active in SPF matters these days, but I don't
know how good an indicator that is. I'm using the Python implementation
myself (also not rhyming with high volume), so I can't say with any
authority which is better.

Scott Kitterman

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

In <NGBBLEIJOEEEBMEIAPBKMELBIFAA.scott@kitterman.com> <spf2@kitterman.com> writes:

>>-----Original Message-----
>>From: owner-spf-devel@v2.listbox.com
>>I'm investigating writing a high-volume postfix policy daemon for
>>SPF. [...]
>>
>>So which library do I pick?
>>
> The author of libspf2 is more active in SPF matters these days, but I don't
> know how good an indicator that is.

Indeed, I have been much more active in SPF matters recently, but I
haven't been that active in working on the libspf2 implementation.
Most of the work done on libspf2 now a days is done by Shevek. He has
received very positive reports about libspf2 running well in very high
volume situations.

My hope was that now that the SPF spec is "finished", I would have
more time on this, but instead I've been sucked into various IETF
politics instead.


*sigh*


-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

spf2@kitterman.com wrote:

>>-----Original Message-----
>>From: owner-spf-devel@v2.listbox.com
>>[mailto:owner-spf-devel@v2.listbox.com]On Behalf Of Per Jessen
>>Sent: Wednesday, June 22, 2005 6:27 AM
>>To: spf-devel@v2.listbox.com
>>Subject: [spf-devel] libspf or libspf2 ?
>>
>>
>>Gents,
>>
>>I'm investigating writing a high-volume postfix policy daemon for
>>SPF. So far I have not come
>>across anything like that already out there. There are couple of
>>daemons written in perl -
>>which doesn't rhyme very well with high-volume.
>>
>>The next step appears to be choosing between libspf and libspf2.
>>This mailing list seems pretty
>>dead, and I can't find a mailinglist for libspf - which in both
>>cases isn't very promising wrt
>>support etc.
>>
>>So which library do I pick?
>>
>>
>>
>>/Per Jessen, Zürich
>>
>>
>>
>The author of libspf2 is more active in SPF matters these days, but I don't
>know how good an indicator that is. I'm using the Python implementation
>myself (also not rhyming with high volume), so I can't say with any
>authority which is better.
>
>
Qpsmtpd is pure perl and can easily outperform
qmail/sendmail/exim/postfix. Ironport seems to have had plenty of luck
writing fast MTAs using python. Neither language is slow. If you want
to go faster than a sustained million messages per hour, I'd highly
consider going commerical.

However, you say you are building a high performance policy daemon for
Postfix, so I'll assume you simply need to be as fast as Postfix which
should be no problem with well written perl, python or just about any
other language.

--
// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// Ecelerity: Run with it. -- http://www.omniti.com/

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Theo Schlossnagle wrote:

> However, you say you are building a high performance policy daemon for
> Postfix, so I'll assume you simply need to be as fast as Postfix which
> should be no problem with well written perl, python or just about any
> other language.

Yeah, that is probably quite true - still, perl is not an option. Are there any other
C-language SPF implementations I should be looking or is libspf/2 all there is?


/Per Jessen, Zürich

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

In <d9bmni$5p0$1@saturn.local.net> Per Jessen <per@computer.org> writes:

> [ ... ] Are there any other
> C-language SPF implementations I should be looking or is libspf/2 all there is?

The only other publicly available C implementation that I know of is
sendmail's, but that is very sendmail specific. I also don't think it
implements the spf-classic spec, but rather some version of one of the
drafts of SID as developed during the IETF's MARID work group lifetime
and then applied to SPF. That was never the right thing to do, and
the spec for SID has changed since then.

But, speaking of conforming to the spec, one of the reasons why I
developed libspf2 was to make sure it conformed to the SPF spec, and I
believe that it is in very good shape. (I was maintianing the SPF
test suite at the time and figured it was easier to write a new SPF
implementation than to make libspf conform.) However, before I start
working on libspf2, I intend to update the SPF conformance test suite.


*sigh*

Too much stuff to do.


-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

wayne wrote:

> Too much stuff to do.

Tell me about it :-(

About libspf2 - what's the status of 1.2.5? The policyd I retrieved from libspf2.org seems to
assume various function calls that were commented out (#if 0/#endif) in libspf2-1.2.5.


/Per Jessen, Zürich

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

>So which library do I pick?

In my experience, neither one is production quality. Summary at
the top of the spfmilter page: http://www.acme.com/software/spfmilter/
---
Jef

Jef Poskanzer jef@mail.acme.com http://www.acme.com/jef/

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Jef Poskanzer wrote:
...
> the top of the spfmilter page: http://www.acme.com/software/spfmilter/

Jef,

The above spfmilter page says the following about libspf2-1.2.5:

--------------------------------------------
libspf2 1.2.5 * Doesn't build.
--------------------------------------------

Does it mean that spfmilter-0.97 doesn't build with libspf2-1.2.5, or
does it mean that libspf2-1.2.5 doesn't build by itself?

I believe it is the former, since I have been able to successfully
configure and compile (with a few warnings) libspf2-1.2.5 on a Fedora
Core-3 system.

--Abhijit.
---------------------------------------------------------------------
Abhijit Hayatnagarkar
Senior Engineer
SPARTA, Inc.

http://www.sparta.com
http://www.isso.sparta.com
http://www.dnssec-tools.org "DNSSEC Tools -- Is your domain secure?"

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

>Does it mean that spfmilter-0.97 doesn't build with libspf2-1.2.5, or
>does it mean that libspf2-1.2.5 doesn't build by itself?
>
>I believe it is the former, since I have been able to successfully
>configure and compile (with a few warnings) libspf2-1.2.5 on a Fedora
>Core-3 system.

libspf2-1.2.5 does not build on my system (FreeBSD 4). I have filed
multiple reports documenting the issues, and received no response.

This is beta-quality software, and should not have a 1.x version number.
---
Jef

Jef Poskanzer jef@mail.acme.com http://www.acme.com/jef/

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

wayne wrote:

> But, speaking of conforming to the spec, one of the reasons why I
> developed libspf2 was to make sure it conformed to the SPF spec, and I
> believe that it is in very good shape. (I was maintianing the SPF
> test suite at the time and figured it was easier to write a new SPF
> implementation than to make libspf conform.) However, before I start
> working on libspf2, I intend to update the SPF conformance test suite.

The funny thing is that then you set out to describe what libspf2 actually
does, and that has become the new spec :)

Koen

--
K.F.J. Martens, Sonologic, http://www.sonologic.nl/
Networking, hosting, embedded systems, unix, artificial intelligence.
Public PGP key: http://www.metro.cx/pubkey-gmc.asc
Wondering about the funny attachment your mail program
can't read? Visit http://www.openpgp.org/

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

On Wed, 2005-06-22 at 12:27 +0200, Per Jessen wrote:
> Gents,
>
> I'm investigating writing a high-volume postfix policy daemon for SPF. So far I have not come
> across anything like that already out there. There are couple of daemons written in perl -
> which doesn't rhyme very well with high-volume.
>
> The next step appears to be choosing between libspf and libspf2. This mailing list seems pretty
> dead, and I can't find a mailinglist for libspf - which in both cases isn't very promising wrt
> support etc.
>
> So which library do I pick?

I think that decision is best left up to you. However since everyone is
throwing in their two bits, I'll throw in the following.

I stress test libSPF under a Linux 2.6.x kernel using a project designed
to discern SPF adoption (amongst other things). The program (DDT) links
libSPF and I run multiple instances of the DDT program with anywhere
from 100 to 1000 threads on dual AMD64 Opteron machines. The database
that DDT operates on contains some 50 Million records and in just over
12 hours which worked out to about 4.1M spf parses per hour or about
86,000 per DDT client. I do not have the need to continue to parse this
database this frequently and as such it operates in smaller setting,
however it should give you an idea as to libSPF's scalability.

Cheers,

James

--
James Couzens,
Programmer

http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7A7C7DCF

"This is not quite as crazy as it sounds, since people knew how
to write small, efficient programs in those days, a skill that
has subsequently been lost." -- Andrew S. Tanenbaum

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

In <42CB83AB.7040603@sonologic.nl> Koen Martens <gmc@sonologic.nl> writes:

> wayne wrote:
>
>> But, speaking of conforming to the spec, one of the reasons why I
>> developed libspf2 was to make sure it conformed to the SPF spec, and I
>> believe that it is in very good shape. (I was maintianing the SPF
>> test suite at the time and figured it was easier to write a new SPF
>> implementation than to make libspf conform.) However, before I start
>> working on libspf2, I intend to update the SPF conformance test suite.
>
> The funny thing is that then you set out to describe what libspf2 actually
> does, and that has become the new spec :)

Yes, the roots of the current SPF spec do happen to have a path
through a stage where it was intended to document libspf2. I think
that misses the point in two ways, however.

First, as I said, my goal of writting libspf2 was, in part, to make
sure it followed the spec. After extensive testing, I think I
accomplished that better than most (all?) other SPF implementations.
That was long I became the SPF spec editor.

Second, when I became the SPF spec editor, parts of the spec that were
libspf2 specific were dropped. The overriding goal was to document
what was out there and to be as compatible as possible with
mengwong-spf-0[01]. The goal was not to document libspf2.


So, libspf2 is still in good shape (I think) as far as conformance to
the spec goes because both libspf2 and the current spec try to follow
mengwong-spf-0[01].



-wayne


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com