On Thu, 2004-07-01 at 09:48, Jeff A. Earickson wrote:
Hi,
I'm relatively new to the list, and I'm puzzling over
libspf vs libspf2. I searched the list archives and note that
there has been a bit of a flame-war in the past, that I don't
want to rekindle. My needs/desires are:
You and me both Jeff. Unfortunately the two or more individuals
responsible for 'libspf2' have ignored my repeated requests for them to
change their very poorly chosen project name. They have chosen this
name quite honestly out of complete arrogance, believing that the
library in question is vastly superior and it deserves the 'libspf
name'. Quite ridiculous.
The only thing more disturbing relating to this, is the complete lack of
action taken by anyone in a position to do so, and the fact that one of
the individuals involved in this happens to be a frequent flyer from
this list.
* an SPF app that builds into sendmail 8.13 (for Solaris 9),
hopefully without having to use a milter. I don't use milters
now and SPF seems important enough that it ought to just be a
part of sendmail. I was surprised that 8.13 didn't include SPF
technology.
libspf v1.0 RC3 is being released today which will also be accompanied
on our website with RedHat SRPMS for 8.13 and possibly 8.12/others.
* While I use a lot of perl with my sendmail, eg MailScanner,
the idea of another perl add-on for SPF makes me groan.
Spf-milter was a nonstarter for me, since it coughed up a
timeout complaint right away during testing. C code patched/added
into sendmail seems a better way to go.
Right you are, and I've been stating this for a long time. Its somewhat
amusing to see people scrambling around in disbelief that there are
people running servers of such scale that and interpretive solution
can't cut it.
Comments from the SPF crowd about which way to go, and why?
No flames about the "other guy" please, just the facts on why you
use one vs the other (and what platform and MTA?).
You should use libspf because its smaller, and more mature. Author of
the test suite or not, I know SPF inside out and I'm quite involved in
the project and other mail related things.
libspf has also been tested with more MTA's and for substantially
longer. Jeff the author of the milter already available has indicated
that when he gets back from holiday he'll make it work with libspf also.
libspf 1.0 is nearly STABLE. And the great thing about it is, it ONLY
implements specifically what the RFC stipulates, nothing more, nothing
less. The new development tree of libspf is about to be made public and
it contains things such as DNS caching which in its self affords such
functionality as statistical analysis, cache dumping/reloading, and
loading your own static queries to supersede or compliment those already
existing. There are additional features present which will be revealed
all in good time.
I honestly don't mind the competition at all, but what really gets under
my skin is the completely subversive attitude being displayed by the
individuals responsible for creating this confusion, and I warned all of
them. I've even had to deal with doling out explanations to hardware
vendors.
I REALLY WISH THE INDIVIDUALS RESPONSIBLE FOR IT WOULD GROW UP AND
CHOOSE A NAME APPROPRIATE TO THEIR PROJECT.
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=0xBD3BF855
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Send us money! http://spf.pobox.com/donations.html
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
signature.asc
Description: This is a digitally signed message part