|
|
|
|
|
|
|
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? |
|
|
|
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. |
|
|
|
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... |
|
|
|
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.
|
|
|
|
The site was offline the last six hours or so due to a hardware upgrade. Sorry for any inconvenience. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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:
draft-lentczner-spf-00.txt
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:
draft-lentczner-spf-00.txt
draft-lentczner-spf-00.html
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. |
|
|
|
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. |
|
|
|
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! |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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:
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. |
|
|
|
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) |
|
|
|
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...
|
|
|
|
Sorry about the broken SRPM links. I've fixed them. They were in just off one level in the srpm/ directory :) |
|
|
|
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.
|
|
|
|
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! |
|
|
|
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. |
|
|
|
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.
|
|
|
|
|
|
|
|
|
|