Tue Nov 9 09:42:31 PST 2004 - Great article surmising MS and SenderID
I read the following GROKLAW story and found it to be very well written and exceptionally informative with great comments/user feedback. Below is what I found most interesting, although I encourge you to read the entire article!

And finally, Microsoft:

Technology alone, however, will not solve this problem. A holistic approach that also includes industry collaboration, legislation, enforcement, and education is necessary to shift the burden from the user to the spammer, resulting in an increase in the reliability of e-mail and of the Internet. This approach also requires that any proposed authentication standard be supported on a global basis, because spam transcends and traverses national borders. Collectively, these measures will help to substantially reduce the amount of junk e-mail delivered to users' mailboxes and optimize users' overall online experience.

See, that's just the problem. The Internet runs on FOSS and increasing numbers of individuals, businesses and government agencies prefer to use Linux, and by choosing a license that excludes all those folks, Sender ID, by Microsoft's own logic, won't work.

Of course, Microsoft has thought of that and they have a plan:

Sender ID also requires modest changes to the e-mail software used by sending servers in certain situations -- mainly to those servers that perform e-mail forwarding. As more and more organizations adopt e-mail authentication techniques, pressure will mount on those who are not participating, because their e-mail will be subjected to greater scrutiny and will be at a greater risk of being blocked by spam filters. Thus, over time, upgrades to existing software will become necessary.

Devilish indeed. But I urge you to read the section on Intellectual Property, beginning on page 8. Their version of what happened with the Internet Engineering Task Force (IETF) is something to behold. It begins like this:

Open Standard. Any authentication system requires cooperation between senders and recipients of e-mail. For that reason, we believe that specifications for these systems must be publicly available and widely implemented -- which is why our Sender ID specifications have been published as Internet Drafts at the Internet Engineering Task Force ("IETF"). A technical interoperability specification is an open standard when it has been ratified in an open, consensus-based process. . . . The Sender ID Framework satisfies these conditions because its specifications are published by the IETF, and because the essential intellectual property rights disclosed to the IETF have been made available on reasonable and non-discriminatory terms that are also free of royalties and other fees.

That is clearly false, as the license attaches terms that preclude its use with any GPL software. They do mention that the IETF working group "has not reached consensus on the proposal and has suspended its work for now -- a decision which is being appealed -- but the disclosure of intellectual property rights to IETF and its publication of Sender ID Framework specifications endures and thereby satisfies the conditions for an open standard." They say the test isn't whether a solution is an open standard isn't whether it has been ratified "through an open-consensus based process", but whether the solution "can be widely adopted. . ." Not a word that I can see in their letter about the GPL conflict. This kind of doubletalk is beyond my heart's comprehension. And here's a scary sentence about the Sender ID license:

"The terms of this license can be accepted by anyone at any time, now or in the future, and will extend to all of Microsoft's essential patent rights needed to implement Sender ID -- not just the essential patent rights that could issue from these patent applications. . . . although this license does not cover other patent rights that might be owned or controlled by parties other than Microsoft and that may be needed to make, use or sell implementations of Sender ID . . . "

By the way, this is what Microsoft's words look like if you copy and paste them, so I had to hand type them:

'l:'chnoiogy ",1011_ 11owt'-v.;r, v�1 not ~wivi.~ this prob1em. A holi~tit appiwJdi that "i1so incl1tdes industry coJiaboratio):, kgislaii�t1, �Hf�r�em~l1t, and education is necess::ry to shift the burden i1'om ~he user to the sp;,nw:wr, n::sii1�ng �n an increase in lhi; rdiahilit:" of e--rnai� and of the TntemeLThis appwadi "iko requ:res that any propo~1ed mdientieition :"�mdardbe supported on a global basis, hteaw3i; spam tn.mseends and traver~:;es national b�n.:kn:" C�!kctivdy" i.hese measures wH1 help to sl,bsLmUally redlice

Now, Groklaw is nonpolitical, and I'm not one to be telling the FTC or any government agency what to do, but you could be a child and see that Microsoft's definition of open standards is ludicrous. Ludicrous and dangerous. It looks to me like Sender ID is just another way to set up conditions to hold back Microsoft's principal competition. They intend that non-Sender ID email will over time become so annoying that we all finally acquiesce and sign their poison pill license. What is the difference between that strategy and Microsoft's tried-and-true anticompetitive trick of arranging it technically so that competitors' applications don't work well in a Windows environment?

There you have it pretty well summed up. Lets hope that the FTC are able to perceive something close to the truth. Its worth mentioning that Microsoft's Harry Katz is on the panel. Funny how that works. Why would someone presenting be permitted to exercise bias through a chair position?

Tue Nov 9 03:43:36 PST 2004 - Sign the SPF Community Position on Sender ID Pledge!
Please review the "SPF Community Position on Sender ID" and if you agree with this position, sign the pledge. Its important that we are able to show organizations such as the FTC that there is a community consensus that SPF-Classic or OpenSPF is precisely what should be implemented instead of the ignorantly designed Sender ID.

Mon Nov 8 20:24:38 PST 2004 - Microsoft ready to assert IP rights on the Internet?
Microsoft Ready to Assert IP rights over the Internet? I suggest that you read this article. And I further stipulate that you consider the following possibilty. What if you had to pay a digital certificate signer to obtain a key for each MX or per domain if you wanted to be able to send email? Its not that you could be forcibly required to do so, but what if the major MTA's out there required that as a preventative measure you had to have a key signed by someone like Verislime? Think about it...

Sun Nov 7 20:30:21 PST 2004 - Revised Sender ID does not impress Apache, Debian
I'm sure that you will all find the following comforting...
Revised Sender ID does not impress Apache, Debian
By Sam Varghese
November 4, 2004 - 11:43AM

The Apache Software Foundation and the Debian GNU/Linux Project have given the revised Sender ID draft submitted by Microsoft a thumbs-down, with both saying that the changes effectively meant nothing.
In a statement, a Debian spokesman said the changes which had been made did not look promising.
A spokesman for the Apache Software Foundation said that unfortunately, these changes in the FAQ did not actually alter the terms of the licence.

"It may be possible to implement portions of the specification without a licence from Microsoft, but Microsoft has indicated their intention to promote the encumbered portions of the specification (PRA) and use their considerable influence to cripple the the unencumbered alternative (MAIL FROM)," the spokesman [for the Apache Foundation] said.

Does Microsoft actually think the ENTIRE world is retarded? Kudos for the ASF and Debian for exercising their spines and standing up and not taking this crap. I urge you to contact your software vendors open source and otherwise, and tell them to speak out against "Sender ID". Its not going to cut it, and if its adopted we're doomed. You can read the full article here.

Fri Oct 29 04:53:40 PDT 2004 - Downtime
The site was offline the last six hours or so due to a hardware upgrade. Sorry for any inconvenience.

Tue Oct 26 08:27:56 PDT 2004 - RC6-pre10 now available
RC6-pre10 is up. This has been running very well and looks to be the real RC6 which barring any bugs will likely be the 1.0 FINAL. Been waiting a long time for this but its been worth the wait! Looking forward to hearing some feedback.

One caveat, I would like to shrink the API. Previously you could call SPF_policy_main and have things handled for you, or you could call SPF_parse_policy and parse a record your self. I've tentatively slated SPF_parse_policy for privitization and I would appreciate some feedback in this area. Are a lot of you using it? Head on over to the developer forums and vote please!

Tue Oct 26 09:12:47 PDT 2004 - If you downloaded RC6-pre10 before this timestamp please re-download it, it was missing built missing an autoconf option. Sorry for the inconvenience.

Tue Oct 19 14:32:25 PDT 2004 - Reentrant SEGV fixed,RC6-pre9 avail
I made a small booboo in RC6-pre8 which if you were attempting multi-threaded use you'd get a lovely segfault. This is fixed with RC6-pre9 and is available for download from the files section and can also be found in CVS.

Sun Oct 17 06:30:28 PDT 2004 - New SPF Draft no good
I have reviewed the new SPF Draft as published by Mark Lentczner and it contains far too many changes in the negative to even consider. libSPF will make no such changes. libSPF will continue to be released as per the last spec released by Meng before he hopped into bed with Micro$hit.

Thu Oct 14 17:06:51 PDT 2004 - SPFv1 Draft finally!
The following information was taken from a recent post to the SPF-DISCUSS mailing list:
Friends -

The SPF v1 draft has been published by the IETF Internet Drafts editor:


For now, I suggest that this be the normative reference: An IETF
Internet Draft URL is stable for six months or more. Copies are also
available on my site, in both text and HTML format:


I'd like to thank Mark for his continued hard work in this area and I will spend time reviewing the draft and seeing where the current libSPF code may differ in functionality and further consider bringing libSPF in-line with the draft where appropriate if at all. A local copy of this draft is also available from the left menu of this site.

Fri Oct 8 07:35:21 PDT 2004 - RC6-pre8 CVS checkout, important autoconf fixes
I made some mistakes in the Autoconf/Autotools setup resulting in linking of gethostbyname instead of gethostbyname_r when compiling with --enable-pthreads. This has been fixed and a new CVS checkout is available for download. Also two new tests have been added to the test suite (run make test) to check for multi-part DNS strings and munged multi-part DNS strings. There are also some other minor changes leading to greater reentrant stability.

Thu Oct 7 09:03:18 PDT 2004 - RC6-pre7 CVS checkout, important parser fixes
I've put up a CVS checkout of RC6 and am calling it pre7. This has taken longer than I had hoped but we're almost there and it was worth the wait given the awesome bug submission by Robin Ehrlich of syntegra.com who caught an interesting bug relating to multi-part DNS string handling. This discovery led me to solve another unknown relating to multiple includes which is also now fixed! In addition I've made more changes that have led to even better reentrant support. It is my goal to try to release a final 1.0 next week as unfortunately this weekend I'm very busy with a release at work.

If any one who is an avid Postfix user would mind playing with the included Postfix patch it would be greatly appreciated as it could use some attention. Thanks everyone for all your support, keep it coming!

Wed Sep 15 22:27:09 PDT 2004 - AOL withdraws support for that SenderID crap.
Well first it was RMS putting the ole hex on Billy Bob's bastardized SPF, then it was Mr. Sam (Courier), soon followed by popular Linux distro Debian and Open Source giant the Apache Software Foundation. To do what? To drop support for the patent encumbered crap known as Sender ID. Today AOL decided it was time to say goodbye, as they have officially withdrawn their support of SenderID. Well if all this doesn't help restore your faith in the fabric that makes up the REAL internet, I don't know what will ;)

If you're looking for the latest and greatest from the libSPF camp have a look in CVS and you'll find a fully thread safe version waiting for you. Even greater is the new Postfix patch against the 2.1 source tree. Last call on bugs has gone out so we should see an RC6 in the next day or so, and barring any crazy bugs coming out of the wood work it will be the last released candidate.

Mon Sep 13 18:09:19 PDT 2004 - SenderID shot down!
The IETF ruled on September 11th how they would proceed with regards MARID. The consensus is aptly summed up with this quote taken from a press release authored by the MARID co-chair's:

"it is the opinion of the co-chairs that MARID should not undertake work on alternate algorithms reasonably thought to be covered by the patent application"

Articles relating to this consensus can be found from the left menu of the main page of this site.

Wed Sep 8 10:53:55 PDT 2004 - RC6-pre1 available for download!
Firstly, sorry for the downtime the last ~10 hours or so, a couple of my boxes were having a lovely little chat over who was to be exercising ownership over the IP address associated with this website :-)

Secondly, head on over to the downloads section for your copy or you may obtain it through CVS (although by the time you do this the code in CVS may have changed, granted this is usually for the better :-)). I've opted to release a pre-RC6 archive due to the important fixes that have been made as well as improvements in the debugging output and performance of the library in addition to the reentrant support.

Mon Sep 6 01:12:39 PDT 2004 - Reentrant testing within CVS
There are reentrant safe (thread-safe) versions of libSPF floating around in the public CVS repository for those of you who are interested and will be a part of RC6 which begins testing early this week. RC6 is likely (providing no new bugs found) going to be the last release candidate before our 1.0 STABLE release.


cvs -d:pserver:anonymous@cvs.codeshare.ca:/pub/spf login

(Hit enter when prompted for password)

cvs -d:pserver:anonymous@cvs.codeshare.ca:/pub/spf co libspf-1.0.0

Sadly the notoriously inconsiderate and down right ignorant alternative to this library has just again changed their API. Despite many claims to be a superior and more stable library it seems that for a third time they have gone through a rewrite leaving users and implementors stranded with broken code. libSPF from day 1 has not changed its API and remains the most stable and consistent "SPF Classic" C implementation available.

Mon Aug 16 16:30:10 PDT 2004 - Technical Difficulties
Due to some uncontrollable hardware difficulties the site suffered some downtime over the course of the weekend which just as Murphy's Law would have it, happened right in the middle of my moving into my new home and of course what better time to have something fail then when one doesn't have internet access =/ At any rate its back up. If you notice any problems with the site (its been moved to a new machine) please don't hesitate to contact me and let me know -> (jcouzens@codeshare.ca)

Mon Aug 9 08:44:21 PDT 2004 - New qmail and Sendmail HOWTO's available!
qmail configuration documentation is now available on-line!
qmail HOWTO is now available on-line.
An updated Sendmail HOWTO is now available on-line as well as in PDF format.

libSPF v1.0 RELEASE CANDIDATE 5 will be released later today...

Wed Jul 28 11:13:38 PDT 2004 - SRPM downloads fixed - by James
Sorry about the broken SRPM links. I've fixed them. They were in just off one level in the srpm/ directory :)

Thu Jul 22 10:40:40 PDT 2004 - RC4 released! - by James
This is probably the most exciting release of libSPF to date! I've received so much exceptional help from people in implementing Autotool and getting binary packages ready, I know it wouldn't have happened without their help. The library now compiles on TWO new architectures, Power PC, and SPARC and has been tested and is known to cleanly compile on Gentoo (x86/x86_64), Solaris (x86/SPARC), Fedora Core 1 & 2 (x86/x86_64), Red Hat 7.3, OSX/Darwin 10.3, OpenBSD 3.5 (x86/x86_64), FreeBSD, Mandrake, and of course, Slackware.

There is a SEGV fixed in this release as well so please do make sure you upgrade if you are running an older release. Its not a major problem, but we aren't doing the world any favours by running old versions now are we :). Added more API documentation and replaced the remaining sprintf's with snprintf's.

Wed Jun 30 06:57:54 PDT 2004 - RC2 Sendmail config problems - by James
Until I can finish RC3 (received a lot of patches thank you all!) Here is some informationt hat you should those of you having problems with Sendmail v8.13.0 and libspf. You can have a look at a HOWTO I just sort of threw together: Sendmail v8.13.0 + libSPF v1.0 HOWTO.

Also, PLEASE check out the forums. I've opened them up a bit to guests who just need to read, you still need to register if you wish to participate. Keep the patches coming!

Sun Jun 27 18:51:59 PDT 2004 - libspf v1.0 RELEASE CANDIDATE 2 - by James
libspf v1.0 RC2 is now available for download. The CHANGELOG is up for viewing. 3 things new with RC2, firstly a macro bug introduced accidentally through testing against a stale binary resulted in RC1 processing '-' and '_' characters as macros even without their counterparts '%{' or '}'. Thanks for Roger Moser for pointing this out! Secondly the x86-64 patch that has been shipped with libspf for the last couple releases has now been applied and is part of this release permanently. Lastly the spfquery tool thats shipped with libspf has had changes made to it to compile properly in FreeBSD.

I would like to please ask those of you who can write patches for any MTA not currently supported by libspf to do so, and in particular Exim and Postfix. Thank you in advance for anyone who can aide in this regard.

Sat Jun 26 22:06:08 PDT 2004 - libspf v1.0 RELEASE CANDDIDATE 1 - by James
Finally made it! This is hopefully one of the final rounds of minor releases! As always see the CHANGELOG for a full list of changes. Most notable is a fix with the Sendmail patch which fixes problems experienced by some RedHat who were also applying patches which were conflicting.

 site design by Travis Anderson