Mailing List Archive

On Sun, 2004-07-25 at 06:05, James Couzens wrote:

> FACT: libSPF has LESS than HALF the size of libspf2 whilst maintaining
> RFC compliance* ergo less code leads to less potential bugs and thus
> definitely leads to greater stability and easier debugging.

* this is true as receipt of code implementing IPv6 was acknowledged
within libSPF-1.0.0-RC4.

--------------------------------------------------------------------------------
| 3 | Pending Patches |
--------------------------------------------------------------------------------
.
Class : RFC Requirement
----------------------------------------------------------------------------
Label : IPv6 Integration
Received : Fri Jul 16 14:32:03 PDT 2004
Status : Patch received and applied, currently undergoing testing.
Author : Stuart Weatherby <stu@codeshare.ca>

Cheers,

James

--
James Couzens,
Programmer
( ( (
((__)) __lib__ __SPF__ '. ___ .'
(00) (o o) (0~0) ' (> <) '
---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo---

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

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

Shevek wrote:
> I suggest that as long as everyone is happy with what they, personally,
> are doing, why bother with this huge "propaganda" campaign? I'm attempting
> to avoid posting on this subject in support of this view.

James wrote:
>I think I've established why. Quite often you will find that silence is
>an admission of guilt.

Ok, I admit it. I'm guilty... of remaining quiet. Perhaps by not confronting your misinformation campaign, I am according credibility to it.

I, like many of the silent majority, have been avoiding this conflict because I don't see it as very productive. There are multiple implementations of SPF, and clearly some people will be confused when there are choices, especially when they are similarly titled. However, this does not mean we should confer rights on the first implementation at the expense of others.

Let's take a look at the names:
libspf - appears official
libspf-alt - appears unprofessional
libspf2 - appears official, may appear to supersede libspf
libspf-wayne - very weird in a community development effort
spflib - appears official, may conflict with libspf

So, basically anything after "libspf" is either:
a) doomed to appear unprofessional, unofficial, and not part of the community effort
or
b) a criminally subversive attempt to supplant the God-given authority of the first libspf author

Based on this, I don't see any problem with libspf3, libspf4, ...

Ideally, we SHOULD have multiple competing implementations because this reduces the security risks associated with monoculture.

Shevek wrote:
> This isn't about the naming of the library, this is about the existence of
> ANY other SPF project whatsoever, other than the one he is sitting on top
> of.

I'm in agreement with this. One of my first introductions to the #spf IRC channel was James telling everyone that Wayne was fragmenting the SPF community with his alternative library, as if a competing implementation was somehow dangerous. This was long before the libspf2/libsrs2 domain (it was before libspf-alt even had a website).

At that time, I was making a decision about which library to use. I downloaded both and read almost the entire source code of both. I was immediately impressed by libspf2 for the following reasons:

1) well thought-out and flexible design (layered approach)
2) better error handling
3) thoroughly tested (comes with test suite)
4) most compliant to the RFC (even more than the Mail::SPF::Query Perl library which is supposed to be the "reference")

Now, according to James, I'm not allowed to make these types of statements without providing substantial proof. Unfortunately for him, I consider documenting the differences between the libraries a complete waste of my time. If you want to understand my statements, then read the source code of the two libraries.

As for the IRC logs you've posted... I'm unable to view them, but I wonder about the copyright implications of posting private conversations (if that is what they were). I also worry about context. I can imagine anyone being curt with someone whom they know to be obnoxious and disagreeable.

James wrote:
>FACT: libSPF is older than libspf2 ergo more time in the wild with
>similar development cycles leads to greater potential stability

This is theoretical "potential". And, it assumes that both libraries started with the same level of instability, which is not the case.

James wrote:
>FACT: libSPF has LESS than HALF the size of libspf2 whilst maintaining
>RFC compliance* ergo less code leads to less potential bugs and thus
>definitely leads to greater stability and easier debugging.

Well, zero code has zero bugs, so in some sense this statement is true. Otherwise, it is not. More code can mean better designed structure and better error handling. It can also mean a more optional features like debugging routines and data caching.

James wrote:
>FACT: Re: "I decided that there needs to be a stable implementation",
>I'm sorry, but I have no clue what world Wayne lives in, but under no
>circumstances is starting another library from scratch going to lead to
>greater stability sooner than simply assisting an existing one, one
>which was nearly complete.

I guess I must inhabit the same world as Wayne, because I've seen many instances where a complete re-write from scratch was better and more cost-effective than continuing with the original project.

James wrote:
>... Well, as anyone
>who knows me either through my posts on here, or through other means
>will probably have already realized, I'm rather outspoken, and it would
>be against the very fabric that makes up my personality to sit here and
>at the very LEAST not say anything.
>
>Remaining silent isn't being mature, in this case its an attempt at
>skirting valid issues.

The problem is that you seem to be the only one who sees the "valid issue" in these diatribes.

Michael R. Brumm

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

Shevek wrote:
> I suggest that as long as everyone is happy with what they, personally,
> are doing, why bother with this huge "propaganda" campaign? I'm attempting
> to avoid posting on this subject in support of this view.

James wrote:
>I think I've established why. Quite often you will find that silence is
>an admission of guilt.

Ok, I admit it. I'm guilty... of remaining quiet. Perhaps by not confronting your misinformation campaign, I am according credibility to it.

I, like many of the silent majority, have been avoiding this conflict because I don't see it as very productive. There are multiple implementations of SPF, and clearly some people will be confused when there are choices, especially when they are similarly titled. However, this does not mean we should confer rights on the first implementation at the expense of others.

Let's take a look at the names:
libspf - appears official
libspf-alt - appears unprofessional
libspf2 - appears official, may appear to supersede libspf
libspf-wayne - very weird in a community development effort
spflib - appears official, may conflict with libspf

So, basically anything after "libspf" is either:
a) doomed to appear unprofessional, unofficial, and not part of the community effort
or
b) a criminally subversive attempt to supplant the God-given authority of the first libspf author

Based on this, I don't see any problem with libspf3, libspf4, ...

Ideally, we SHOULD have multiple competing implementations because this reduces the security risks associated with monoculture.

Shevek wrote:
> This isn't about the naming of the library, this is about the existence of
> ANY other SPF project whatsoever, other than the one he is sitting on top
> of.

I'm in agreement with this. One of my first introductions to the #spf IRC channel was James telling everyone that Wayne was fragmenting the SPF community with his alternative library, as if a competing implementation was somehow dangerous. This was long before the libspf2/libsrs2 domain (it was before libspf-alt even had a website).

At that time, I was making a decision about which library to use. I downloaded both and read almost the entire source code of both. I was immediately impressed by libspf2 for the following reasons:

1) well thought-out and flexible design (layered approach)
2) better error handling
3) thoroughly tested (comes with test suite)
4) most compliant to the RFC (even more than the Mail::SPF::Query Perl library which is supposed to be the "reference")

Now, according to James, I'm not allowed to make these types of statements without providing substantial proof. Unfortunately for him, I consider documenting the differences between the libraries a complete waste of my time. If you want to understand my statements, then read the source code of the two libraries.

As for the IRC logs you've posted... I'm unable to view them, but I wonder about the copyright implications of posting private conversations (if that is what they were). I also worry about context. I can imagine anyone being curt with someone whom they know to be obnoxious and disagreeable.

James wrote:
>FACT: libSPF is older than libspf2 ergo more time in the wild with
>similar development cycles leads to greater potential stability

This is theoretical "potential". And, it assumes that both libraries started with the same level of instability, which is not the case.

James wrote:
>FACT: libSPF has LESS than HALF the size of libspf2 whilst maintaining
>RFC compliance* ergo less code leads to less potential bugs and thus
>definitely leads to greater stability and easier debugging.

Well, zero code has zero bugs, so in some sense this statement is true. Otherwise, it is not. More code can mean better designed structure and better error handling. It can also mean a more optional features like debugging routines and data caching.

James wrote:
>FACT: Re: "I decided that there needs to be a stable implementation",
>I'm sorry, but I have no clue what world Wayne lives in, but under no
>circumstances is starting another library from scratch going to lead to
>greater stability sooner than simply assisting an existing one, one
>which was nearly complete.

I guess I must inhabit the same world as Wayne, because I've seen many instances where a complete re-write from scratch was better and more cost-effective than continuing with the original project.

James wrote:
>... Well, as anyone
>who knows me either through my posts on here, or through other means
>will probably have already realized, I'm rather outspoken, and it would
>be against the very fabric that makes up my personality to sit here and
>at the very LEAST not say anything.
>
>Remaining silent isn't being mature, in this case its an attempt at
>skirting valid issues.

The problem is that you seem to be the only one who sees the "valid issue" in these diatribes.

Michael R. Brumm

-------
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 Sun, 2004-07-25 at 13:42, Michael R. Brumm wrote:

> Ok, I admit it. I'm guilty... of remaining quiet. Perhaps by not
> confronting your misinformation campaign, I am according credibility
> to it.

This is not a misinformation campaign. Wow Michael welcome to the "Ben
Mankin and Wayne Schlitt denial of reason club". Funny how a third
individual from the same project would say the same things as the
others...

> I, like many of the silent majority, have been avoiding this conflict
> because I don't see it as very productive. There are multiple
> implementations of SPF, and clearly some people will be confused when
> there are choices, especially when they are similarly titled. However,
> this does not mean we should confer rights on the first implementation
> at the expense of others.

I'm aware of how counterproductive it is.

> Let's take a look at the names:
> libspf - appears official
> libspf-alt - appears unprofessional
> libspf2 - appears official, may appear to supersede libspf
> libspf-wayne - very weird in a community development effort
> spflib - appears official, may conflict with libspf
>
> So, basically anything after "libspf" is either:
> a) doomed to appear unprofessional, unofficial, and not part of the
> community effort
> or
> b) a criminally subversive attempt to supplant the God-given authority
> of the first libspf author

Now just how is this my fault or problem? Should not Wayne have taken
this into consideration before endeavouring upon his little journey?

> Based on this, I don't see any problem with libspf3, libspf4, ...

Irregardless of the irrelevant material you just posted, its confusing.
Why does Microsoft not tolerate "mikerowesoft.com" or "lindows" as
names? Because they both share the an ability to misrepresent Microsoft
in any fashion, irregardless if it could be positive or negative, its
misleading to people, and that is why its wrong.

> Ideally, we SHOULD have multiple competing implementations because
> this reduces the security risks associated with monoculture.

Yes, there is nothing wrong with this. I was perfectly content with
Wayne's libspf-alt. In fact, I nearly agreed to work with him on
several occasions.

http://moscow.6o4.ca/index.html

Email & IRC logs of my emails to Wayne Schlitt.

> I'm in agreement with this. One of my first introductions to the #spf
> IRC channel was James telling everyone that Wayne was fragmenting the
> SPF community with his alternative library, as if a competing
> implementation was somehow dangerous. This was long before the
> libspf2/libsrs2 domain (it was before libspf-alt even had a website).
> At that time, I was making a decision about which library to use. I
> downloaded both and read almost the entire source code of both. I was
> immediately impressed by libspf2 for the following reasons:

You stepped into the middle of a public discussion, and perhaps you
didn't glean the proper context from the situation, so I'll clarify for
you. Just as Shevek and Wayne were accusing me of "fragmenting" the
community, so could I have just as easily (and did) retort back to him.
> 1) well thought-out and flexible design (layered approach)
> 2) better error handling
> 3) thoroughly tested (comes with test suite)
> 4) most compliant to the RFC (even more than the Mail::SPF::Query Perl
> library which is supposed to be the "reference")
>
> Now, according to James, I'm not allowed to make these types of
> statements without providing substantial proof. Unfortunately for him,
> I consider documenting the differences between the libraries a
> complete waste of my time. If you want to understand my statements,
> then read the source code of the two libraries.

I dunno what to think of you. You've done a fair amount of damage your
self by charging for your plugin, and I think this is absolutely
shameful. SPF isn't supposed to be about making money, its supposed to
be about promoting ANTI-FORGERY, I really believe you should just give
it away. Its not like you really put much work into it, or am I
mistaken in some way? (That may sound snarky, but it is not, its an
honest question, as I am not overly familiar with the process of hooking
a gui around a dll in windows).

> As for the IRC logs you've posted... I'm unable to view them, but I
> wonder about the copyright implications of posting private
> conversations (if that is what they were). I also worry about context.
> I can imagine anyone being curt with someone whom they know to be
> obnoxious and disagreeable.

There are no copyright implications LOL. If you say something to me,
then you are giving this information to me. What I do with it is up to
me. Unless you a) prior to speech stipulate that further speech is
predicated purely on b) my accepting not to publish conversation
subsequent to agreement.

My cable connection had an untimely outage shortly after I posted. You
can view it from here:

http://moscow.6o4.ca/index.html

I've removed the "personal" logs which I added my own commentary to aide
in giving it context where it was necessary. All that remains there now
are logs, only edited to reflect their date of origin.

> James wrote:>FACT: libSPF is older than libspf2 ergo more time in the
> wild with
> >similar development cycles leads to greater potential stability
>
> This is theoretical "potential". And, it assumes that both libraries
> started with the same level of instability, which is not the case.

Hey, Wayne used my library as a reference lest you forget, therefore how
could mine be any less stable than his? Quite frankly its a shame your
post doesn't have more actual valid content.

> Well, zero code has zero bugs, so in some sense this statement is
> true. Otherwise, it is not. More code can mean better designed
> structure and better error handling. It can also mean a more optional
> features like debugging routines and data caching.

Michael, forgive me if I am wrong here, but adding things "data caching"
are more likely to ADD bugs then to remove them. And If you have a peep
into my library, I've got more debugging output then you can shake a
stick at, and it certainly isn't taking up too much space. Debugging
code should not bloat your library.

"More code can mean better designed structure and better error handling"
is another one of those statements that really doesn't say anything. My
point, and I really don't see how you can contest it, is so incredibly
simple. Its not a hard statement to understand. If you have more code,
you likely have more bugs, it doesn't get much simpler than that. In
addition to this, a larger codebase is likely to take longer to
stabilize.

> I guess I must inhabit the same world as Wayne, because I've seen many
> instances where a complete re-write from scratch was better and more
> cost-effective than continuing with the original project.

You live in Kansas too? Because thats some backwards ass world. Wayne
was able to write his implementation as quickly as he states because he
had a nearly complete C implementation as reference, OR he simply
continued work on his original library and opted to tout it as "second
generation" in error when it was just perfectly entitled "libspf-alt"

> The problem is that you seem to be the only one who sees the "valid
> issue" in these diatribes.

This is soooooo not so. Unfortunately, or perhaps fortunately, many
people have opted to post to me offlist rather than pollute the list
further.

I was in error in making my original post in here, I did it out of pure
frustration over having my very valid complaint ignored. The real
travesty is that Wayne is supposed to be in some position of authority
is he not? Do people not look to him for direction? Shall we all
behave in this fashion?

If you actually have something insightful to say Michael, please post to
the list, otherwise please refrain from adding to this thread and send
it to me privately. After going through your entire message its was
practically void of content that shed light upon anything.

Cheers,

James

--
James Couzens,
Programmer
( ( (
((__)) __lib__ __SPF__ '. ___ .'
(00) (o o) (0~0) ' (> <) '
---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo---

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

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

This will probably be the only reply I make to James on the subject of
libspf vs libspf2.

James loves to have long "discussions", I don't.


Summary:

Libspf2 (aka libspf-alt) has long had support for more features, both
required by the SPF RFC and for compatibility with the perl M:S:Q
implementation, it has better error handling and has had support for
more MTAs, it is thread safe and runs faster. As a result, all the
stuff that has been going on with libspf has been just catching up to
libspf2 and reinventing the wheel. There is *nothing* that libspf
does that libspf2 doesn't, and there are lots of things that libspf2
does that libspf doesn't.

The things that libspf2 does includes support for RFC requirements
such as IPv6 and correct handling of %{r}, non-RFC features from
M:S:Q such as override/fallback, secondary MX support, and DNS
caching, and support for MTAs such as Zmailer, Exchange and Exim.



In <1090760699.25207.107.camel@code3> James Couzens <jcouzens@6o4.ca> writes:

> On Sun, 2004-07-25 at 04:09, Shevek wrote:
>
>> This isn't about the naming of the library, this is about the existence of
>> ANY other SPF project whatsoever, other than the one he is sitting on top
>> of.
>
> Excuse me? Were you not so arrogant and completely void of humility
> Shevek, and had actually apologized* to me, I would be working on
> libspf-alt for several weeks.

Ok, the back-story to this is:

James and I had talked about merging our efforts for a long time.
James kept saying that I needed to stop working on libspf-alt and then
maybe some day in the future we could use it as a base for libspf2.
At the time, libspf-alt was more feature complete and bug-free than
libspf. Nothing happened for a long time, but when Shevek decided to
stop waiting on James and took a couple of days to write his SRS
implementation, suddenly James decided he was interested in working on
libspf-alt as long as I excluded Shevek and used James' SRS
implementation.

Unfortunately, Shevek had already approached me about merging efforts.
I decided to ask both Shevek and James a simple question: "Are you
willing to work with the other?" I would then work with any and all
who were willing to work with others. Shevek answered instantly with
a "yes", he would work with James. James took a very long time to not
answer the question, and I finally gave up trying to get an answer out
of him.

As a result, I'm now working with Shevek and not James.



> Wayne formerly has been a complete gentleman to me. He submitted
> patches to my library, and when he decided he still wanted to write his
> own, he even notified me before he published letting me know what he was
> going to do. I was disappointed, because it would mean he would no
> longer be contributing.

Actually, I did continue to send bug reports and update the test code
and spfquery code for libspf. I did *not* stop contributing. (Yes, I
know, you have removed most (all?) of the code that I contributed.)


> Conversation with Wayne (grumpy)
> irc.pobox.com Sat Jul 24 18:50:05 PDT 2004
> http://moscow.6o4.ca/wayne.html
>
> [.selected parts of the IRC log taken out of order snipped]

For those who care, this conversation was on the public #spf channel
of irc.pobox.com.

Since it is relatively short, I have added the complete transcript to
the end of this post.


> FACT: libSPF is older than libspf2 ergo more time in the wild with
> similar development cycles leads to greater potential stability

The initial code release of libspf was on Jan 24th. The initial code
release of libspf2 was on Feb 23rd. They have both been out around
the same amount of time.


> FACT: libSPF has LESS than HALF the size of libspf2 whilst maintaining
> RFC compliance* ergo less code leads to less potential bugs and thus
> definitely leads to greater stability and easier debugging.

There are potential bugs and real bugs. The libspf RC4 release still
doesn't get such things this right (it fails, when it should pass):

spfquery -i 206.222.212.234 -s foo@spf.midwestcs.com -h asdf

Of course, you would have known about such problems if you had
bothered to use the test code that I sent you months ago.

Even though finding bugs in your code is very easy, I have decided
that it is a waste of my time to do so.


> FACT: libSPF is not "reinventing the wheel". Its absurd to think that
> my library which has been in development LONGER would be reinventing
> anything, I find that statement rather comical.

You started re-inventing the wheel once libspf fell behind libspf2 in
terms of features and such. Yes, you have now added autoconf stuff,
just like libspf2 had months ago. Yes, you have now added IPv6
support, just like libspf2 had months ago. Yes, you are now toying
with adding DNS caching, just like libspf2 had months ago. Yes, you
are looking for people to support things like Exchange and Exim, just
like libspf2 had months ago.


Libspf2 has had things that libspf still doesn't have from the very
first release.


> FACT: Re: "I decided that there needs to be a stable implementation",
> I'm sorry, but I have no clue what world Wayne lives in, but under no
> circumstances is starting another library from scratch going to lead to
> greater stability sooner than simply assisting an existing one, one
> which was nearly complete.

Uh huh...



Anyway, here are the IRC logs:

Jul 24 14:57:59 <grumpy> oh great.
Jul 24 14:58:06 <grumpy> RMS on MXCOMP about freesoftware
Jul 24 14:58:16 * grumpy goes to read the damage
Jul 24 14:58:49 <gmc> ah yes
Jul 24 14:58:56 <gmc> just saw it
Jul 24 14:59:51 <grumpy> well, it could be worse.
Jul 24 15:00:25 * grumpy really wishes that MS would have "done the right thing" weeks ago.
Jul 24 15:01:00 * grumpy wonders if RMS will get smacked by Ted Hardie for not being a member of the MARID list and posting to it.
Jul 24 15:01:19 <gmc> ah yes and he's discussing hidden agenda's too
Jul 24 15:23:21 * james wishes grumpy would have "done the right thing" weeks ago
Jul 24 15:24:17 <grumpy> I did. I gave up waiting for you and renamed my library for "alternate" to the second generation implementation, like it is.

[snip]

Jul 24 17:46:40 <james> grumpy its no, you are actively making use of 'libspf2' as a name
Jul 24 17:46:44 <james> s/no/not
Jul 24 17:46:50 <james> and i'm tired of this infighting
Jul 24 17:47:20 <james> I will even pay for "libspf-alt.org"
Jul 24 17:47:26 <grumpy> ok james.... then stop fighting
Jul 24 17:47:29 <james> hell, I'll even host your site if that helps
Jul 24 17:47:50 <james> I will not sit idle whilst you use that name
Jul 24 17:48:01 <james> I'm getting overwhelmed with emails questioning what is going on
Jul 24 17:56:53 <james> well?
Jul 24 20:20:37 <james> you know silence is often an admission of guilt
Jul 24 20:24:36 <grumpy> james: I have talked to you at length quite a few times. One thing I learned it is rarely productive to talk with you.
Jul 24 20:28:54 <james> well
Jul 24 20:28:59 <james> why don't you explain to the list what your problem is
Jul 24 20:29:19 <james> you remain silent in the wake of my acusations
Jul 24 20:29:28 <james> and as I stated, silence is often viewed as an admision of guilt
Jul 24 20:29:39 <james> why don't we get some great discussion about your poor choice of domain name on the list
Jul 24 20:29:49 <james> there was nothing wrong with libspf-alt
Jul 24 20:29:50 <grumpy> james: are you willing to work with Shevek? As you well know, Shevek says that he is willing to work with you.
Jul 24 20:30:05 <james> Can shevek stop lying?
Jul 24 20:30:23 <grumpy> I dunno, and I don't care if you can or cannot stop lying either
Jul 24 20:30:28 <james> I do not lie
Jul 24 20:30:33 <james> or better
Jul 24 20:30:43 <james> I have not lied to you or shevek to date
Jul 24 20:31:19 <james> neither have I misrepresented my stance or position about my focus, nor anything else relating to this or other similar projects
Jul 24 20:32:57 <james> http://moscow.6o4.ca/shevek_log2.html <- why don't you ACTUALLY read the truth
Jul 24 20:33:04 <james> and see that he STILL has not apologized to me
Jul 24 20:33:16 <james> you are willing to maintain a stance on a subject you know nothing about
Jul 24 20:33:23 <james> because you refuse to read the information
Jul 24 20:33:47 <grumpy> Well, James, here is the problem. I *have* read that a couple of time.
Jul 24 20:33:56 <james> well then I must have your ip wrong
Jul 24 20:33:57 <grumpy> you shouldn't assume so much stuff
Jul 24 20:34:04 <james> I did not assume
Jul 24 20:34:18 <james> I thought I had tracked your ip to actual hits, or rather the lack there of
Jul 24 20:34:24 <grumpy> well, apparently you assume you know all the IP addresses that I use
Jul 24 20:34:26 <james> I was going on the basis of the ip address you were using when we last spoke
Jul 24 20:35:16 <james> well why is it that you feel I should work with someone who will not apologize to me, and believes that I have made "no significant contribution" to this project
Jul 24 20:35:32 <grumpy> but as far as other lies/deceptions from you, we could start with your initial claim that you would be "releasing your library within two days" (pharaphrased) when it actually took a couple of weeks before we could get a buggy library out of you
Jul 24 20:35:49 <james> thats not a lie, or a deception, thats a missed deadline
Jul 24 20:35:57 <james> please do not try to associate a lie with me in that manner
Jul 24 20:35:58 <grumpy> It was trusting your claim that lead me to abandon my initial SPF implementation
Jul 24 20:36:04 <grumpy> oh bull, you kept stalling
Jul 24 20:36:06 <grumpy> and talling
Jul 24 20:36:06 <james> well whose fault is that?
Jul 24 20:36:17 <james> does that give you the right to behave as you have?
Jul 24 20:36:29 <grumpy> james: I wrote the complete second implementation in less time than it took for your "delay"
Jul 24 20:36:35 <grumpy> yes, it does.
Jul 24 20:36:49 <grumpy> my implementation supports more MTAs and has more features
Jul 24 20:36:52 <james> I'm afraid I fail to see your point
Jul 24 20:36:53 <grumpy> you are reinventing the wheel
Jul 24 20:36:58 <james> excuse me?
Jul 24 20:37:00 <grumpy> you are hurting the SPF community
Jul 24 20:37:07 <james> no YOU are
Jul 24 20:37:11 <james> and what is this all about features?
Jul 24 20:37:14 <james> thats not the point
Jul 24 20:37:14 <grumpy> you are causing confusing with your backward, incomplete implemntation
Jul 24 20:37:20 <james> you are bloating the unecessary
Jul 24 20:37:31 <james> there is nothing backwards about it
Jul 24 20:37:40 <james> and I'm sorry, but my code has been out in the public before yours
Jul 24 20:37:45 <james> and thus, there is no reinventing anything here
Jul 24 20:37:48 <grumpy> not by much
Jul 24 20:37:51 <grumpy> yes there is.
Jul 24 20:38:06 <james> I fail to see what is being reinvented
Jul 24 20:38:06 <grumpy> you are still adding features that I had in myt initial release
Jul 24 20:38:17 <james> please understand grumpy
Jul 24 20:38:24 <james> your implementation is too big
Jul 24 20:38:31 <james> you should only be implementing the RFC
Jul 24 20:38:46 <james> people who implement this need to be able to reference something thats as tight and to the point as possible
Jul 24 20:38:58 <james> I don't expect that sendmail or any other mta would implement any external library
Jul 24 20:39:01 <james> they will write it themselves
Jul 24 20:39:13 <james> of what benefit is it to them to have to look at thousands of lines of unnecessary code
Jul 24 20:39:23 <james> and quite frankly, you are trying to boast about how fast you can write something
Jul 24 20:39:28 <james> you've been hanging out with shevek too long
Jul 24 20:39:32 <james> speed is not of consequence here
Jul 24 20:39:36 <grumpy> james: convince Meng to pull out things like the fallback/override stuff, and the 2ndary mx stuff, and dns caching... If you do that, I'll consider pulling stuff out of my implmenetation
Jul 24 20:39:40 <james> not in the manner you are trying to attribute it
Jul 24 20:39:50 <james> and if you were not paying attention, I had to write libsrs as well
Jul 24 20:39:58 <james> so I've written two full implementations
Jul 24 20:40:10 <james> I'm not saying you should pull it out
Jul 24 20:40:21 <james> I'm saying that there needs to be STABILITY before FEATURES
Jul 24 20:40:26 <grumpy> james: I realize that you can't code anywhere near as fast as I can. that's your problem
Jul 24 20:40:37 <james> wrong
Jul 24 20:40:46 <james> I have a busy schedule, and a job, so sue me
Jul 24 20:41:01 <grumpy> james: good point. It was *because* I was helping test your code and saw how bad it is that I decided that there needs to be a stable implementation. that's what my implementation is.
Jul 24 20:41:16 <james> now hang on a minute, you are going to have to back that statement up
Jul 24 20:41:23 <james> what is so "bad" or unstable about it?
Jul 24 20:41:54 <james> and how thoughtful and unselfish of you to instead of helping fix my supposedly "bad code", you will start from scratch on your own
Jul 24 20:42:03 <grumpy> james: I don't care. Your implemenation still doesn't do everything that M:S:Q does, it doesn't have support for as many MTAs, it doesn't do everything the RFC calls for and you are reinventing the wheel
Jul 24 20:42:09 <james> grumpy tsk tsk
Jul 24 20:42:13 <james> do not skirt the issue
Jul 24 20:42:13 <grumpy> james: I sent you patches
Jul 24 20:42:17 <james> please qualify your statement
Jul 24 20:42:27 <grumpy> james: you are not productive to talk with.
Jul 24 20:42:28 <grumpy> bye
Jul 24 20:42:31 <james> you are claiming its bad code, please qualify this
Jul 24 20:42:32 <james> hahahahaha
Jul 24 20:42:34 <james> so you walk away
Jul 24 20:42:35 <james> good job
Jul 24 20:42:37 <james> way to stand up
Jul 24 20:42:52 <james> man you are getting worse all the time
Jul 24 20:42:58 <james> you sling mud at a wall, and then you can't even back it up
Jul 24 20:43:52 <james> man this reall is pathetic
Jul 24 20:44:05 <james> be a man and actually qualify the statements that come from your mouth, or keyboard
Jul 24 20:45:24 <james> well everyone here please bear witness to this refusal to supply proof with acusation
Jul 24 21:02:29 <james> man thats so funny grumpy
Jul 24 21:02:35 <james> 06:42PM <grumpy> james: you are not productive to talk with.
Jul 24 21:02:43 <james> let me translate for everyone
Jul 24 21:03:03 <james> "I am saying things that I can not qualify with reason or proof so i'm leaving here before I make more of an ass of myself"
Jul 24 21:03:18 <james> you call me a liar, and then don't prove it
Jul 24 21:03:25 <james> then you say my code is bad, but you can't supply a reason
Jul 24 21:03:33 <james> who needs to grow up here, me or you?
[nothing more was said on #spf until you got on]


-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

Michael R. Brumm wrote:
> Let's take a look at the names:
> libspf - appears official
> libspf-alt - appears unprofessional
> libspf2 - appears official, may appear to supersede libspf
> libspf-wayne - very weird in a community development effort
> spflib - appears official, may conflict with libspf
>
> So, basically anything after "libspf" is either:
> a) doomed to appear unprofessional, unofficial, and not part of the
> community effort
> or
> b) a criminally subversive attempt to supplant the God-given authority
> of the first libspf author

James wrote:
> Now just how is this my fault or problem? Should not Wayne have taken
> this into consideration before endeavouring upon his little journey?

It's not your *fault*, nor is it any one else's. Everyone wants to be on the same level playing field. Whether that's your *problem* or not is up to you.

Michael R. Brumm wrote:
> Based on this, I don't see any problem with libspf3, libspf4, ...

James wrote:
> Irregardless of the irrelevant material you just posted, its confusing.
> Why does Microsoft not tolerate "mikerowesoft.com" or "lindows" as
> names? Because they both share the an ability to misrepresent Microsoft
> in any fashion, irregardless if it could be positive or negative, its
> misleading to people, and that is why its wrong.

Microsoft uses many strangle-hold legal tactics to prevent any competition in any way. Are you suggesting that you wish to follow their lead?

In an egalitarian, open-source development community, there are many "libc"s, "libdns"s, "libsmtp"s, etc... (many not even differentiated by a number or author name). Obviously, the more successful ones are the ones that are better known and used.

libXXXX is known to translate as "(usually C) programming library for the XXXX technology". I don't think anyone creating a "libsmtp" feels threatened by someone who creates another "libsmtp", "libsmtp2", or "libsmtp++". It's just plain silly. GNU should not have created another libc! Down with GNU!

James wrote:
> Yes, there is nothing wrong with this. I was perfectly content with
> Wayne's libspf-alt. In fact, I nearly agreed to work with him on
> several occasions.

Yes, I'm sure you would be *very* happy if everyone named their SPF libraries like so:

libspf-alt-sex-pictures
libspf-st00pid
libspf-not-working

Michael R. Brumm wrote:
> I'm in agreement with this. One of my first introductions to the #spf
> IRC channel was James telling everyone that Wayne was fragmenting the
> SPF community with his alternative library, as if a competing
> implementation was somehow dangerous. This was long before the
> libspf2/libsrs2 domain (it was before libspf-alt even had a website).
> At that time, I was making a decision about which library to use. I
> downloaded both and read almost the entire source code of both. I was
> immediately impressed by libspf2 for the following reasons:

James wrote:
> You stepped into the middle of a public discussion, and perhaps you
> didn't glean the proper context from the situation, so I'll clarify for
> you. Just as Shevek and Wayne were accusing me of "fragmenting" the
> community, so could I have just as easily (and did) retort back to him.

Wrong discussion. As I said, "This was long before the libspf2/libsrs2 domain". It was you who stepped into a discussion between Meng and me about Wayne's lack of a website for "libspf-alt". You jumped in to announce that Wayne was fragmenting the community with an alternative library, that he was wasting his time, and basically that his library was bloated with unnecessary features (some of which you later added to your library, like the DNS cache).

I argued that I had read both your libraries and found Wayne's had a better overall design. I also told you that competing libraries was a good thing. Wayne privately messaged me that he was desperately trying to cooperate with you, and so I then backed off from telling you what I really thought of your very unprofessional remarks.

James wrote:
> I dunno what to think of you. You've done a fair amount of damage your
> self by charging for your plugin, and I think this is absolutely
> shameful. SPF isn't supposed to be about making money, its supposed to
> be about promoting ANTI-FORGERY, I really believe you should just give
> it away. Its not like you really put much work into it, or am I
> mistaken in some way? (That may sound snarky, but it is not, its an
> honest question, as I am not overly familiar with the process of hooking
> a gui around a dll in windows).

The plug-in is freeware. I sold it to a company under the agreement that they would also keep it freeware. Gee, do you think I could have gotten more money if I had not made this stipulation? BTW, I quietly donated over 15% of the proceeds to certain individuals in the community which I thought were doing exceptional jobs.

The source code (.c and .h files) for my "SMTP SPF Filter" is about half the size of libspf2 (in bytes, not lines). The source code for the GUI that controls it ("SMTP SPF Filter MMC") is about a quarter the size of libspf2. So I guess all together its around 3/4 the size of libspf2. Oh, and I also ported libspf2 to Win32 and contributed that code back to the project. Since libspf is "so much smaller than libspf2", I'm guessing I've written more SPF related code than you.

I worked 60+ hour weeks on it from April 25th until June 1st, 2004 and basically put all other consulting work on hold at that time. The actual code itself didn't take that long to write. The problem was that I had to use undocumented and barely documented APIs. Microsoft is required to expose these APIs by law, but they aren't really required to document them fully. So, it meant a lot of trial and error, debugging, and flat-out guessing about how to do things.

James wrote:
> This is soooooo not so. Unfortunately, or perhaps fortunately, many
> people have opted to post to me offlist rather than pollute the list
> further.

People I don't even know have sent me e-mails saying that they didn't want to become part of this thread, but they thanked me for writing what they would have said. Personally, I'm still not sure whether entertaining this thread was worth it.

Michael R. Brumm

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

Michael

On Thu, 2004-07-29 at 02:22, Michael R. Brumm wrote:

> It's not your *fault*, nor is it any one else's. Everyone wants to be
> on the same level playing field. Whether that's your *problem* or not
> is up to you.

Michael, this entire thing is directly laying in Wayne's lap. He opted
to proceed with the renaming, therefore he is to blame is he not? Hey
thats not only accurate, but truthful, so stop shaking the finger in my
direction just because I'm the one kicking shit around the room in
protest.

> Microsoft uses many strangle-hold legal tactics to prevent any
> competition in any way. Are you suggesting that you wish to follow
> their lead?

You've gone and twisted my illustration around thus illustrating that
you are either ignorant of its intended meaning, or simply grasping at
anything you may to make yet ANOTHER non-point.

Perhaps I should use a different example, so you don't get so easily
sidetracked. How many coffee houses do you see out there named
Starlucks? or burger joints named McRonalds? or perhaps BugerQueen?

> In an egalitarian, open-source development community, there are many
> "libc"s, "libdns"s, "libsmtp"s, etc... (many not even differentiated
> by a number or author name). Obviously, the more successful ones are
> the ones that are better known and used.

> libXXXX is known to translate as "(usually C) programming library for
> the XXXX technology". I don't think anyone creating a "libsmtp" feels
> threatened by someone who creates another "libsmtp", "libsmtp2", or
> "libsmtp++". It's just plain silly. GNU should not have created
> another libc! Down with GNU!

Ummmmm Michael, are you sure you read that rubbish before you posted it,
because I dare say that qualifies as complete and utter Poopie, and
speaking of which I think I left a bowl behind yesterday who's odour
carried a more refreshing scent and was quite likely a better use of
space then this entire document you've produced.

What has been done is just absolutely stupid, and has removed from me
the ability to even PUBLISH a successive version(s) of my library. I'm
STILL in complete and utter shock that there are actually people
defending this position. For crying out loud you should READ your own
email to see how absolutely LUDICROUS you sound. I think I've heard
more believable explanations on COPS with people trying to justify their
theft of auto or other item.

You see this?

-rw-r--r-- 1 root root 732294 Apr 27 04:42 libxml.a
-rwxr-xr-x 1 root root 594232 Apr 27 04:42 libxml.so.1.8.17

-rw-r--r-- 1 root root 1449288 Apr 30 12:05 libxml2.a
-rwxr-xr-x 1 root root 1129432 Apr 30 12:05 libxml2.so.2.6.9

I'll never be able to do that with my library. GREAT JOB GUYS.

Your logic is NONEXISTENT. Lets have a look, just so you can see how
ignorant your "view" or "explanation" has you sounding:

A directory of freely available C libraries:
http://directory.fsf.org/libs/c/

How many libraries in there do you see doing what you boys are up to
hrm? Lets look at CGI libraries for example:

qDecoder - [LGPL] - 2003-01-27 - C library for creating CGI software
LibCGI - [LGPL] - 2003-12-16 - Library for writing CGI applications
cgicc - [GPL-2] - 2004-06-19 - C++ class library for writing CGI apps
Cgi-util - [LGPL] - 2001-08-23 - C library for developing Web programs

WOW! Look at THAT! One, two, three, FOUR, I see FOUR C CGI libraries
with different names! And somehow, bless their little hearts they have
managed to DELIBERATELY choose FOUR UNIQUELY different names for them
selves.

Do you need MORE examples? Lets have a look!

Glibc - [LGPL] - 2004-06-21 - Library for GNU/Hurd and GNU/Linux
Diet libc - [GPL-2] - 2004-03-29 - Library for creating small,
statically linked binaries

Man that Diet libc, thats some trick isn't it! Simply fantastic how you
can clearly not confuse the two libraries together.

> Yes, I'm sure you would be *very* happy if everyone named their SPF libraries like so:
>
> libspf-alt-sex-pictures
> libspf-st00pid
> libspf-not-working

Michael, just how OLD are you? I'm quite likely the youngest person on
this list, and the lot of you are acting like bloody children.

> Wrong discussion. As I said, "This was long before the libspf2/libsrs2
> domain". It was you who stepped into a discussion between Meng and me
> about Wayne's lack of a website for "libspf-alt". You jumped in to
> announce that Wayne was fragmenting the community with an alternative
> library, that he was wasting his time, and basically that his library
> was bloated with unnecessary features (some of which you later added
> to your library, like the DNS cache).

If I had logs of the situation I would definitely post them, but I do
not. My recollection of the event what I came in and was instantly put
off with the topic for conversation, had no clue who you were, and
didn't take kindly to your abrasive attitude.

> I argued that I had read both your libraries and found Wayne's had a
> better overall design. I also told you that competing libraries was a
> good thing. Wayne privately messaged me that he was desperately trying
> to cooperate with you, and so I then backed off from telling you what
> I really thought of your very unprofessional remarks.

Funny, with such a vivid recount of the events, one would think you
would have raised the point where I approached you and apologized for
coming at you like I did, we both mused about it and things seemed fine
in my books, in fact I even queried you to ensure that things were at
peace, a query that you conceded to. Have you been holding some sort of
grudge this entire time?

> The plug-in is freeware. I sold it to a company under the agreement
> that they would also keep it freeware. Gee, do you think I could have
> gotten more money if I had not made this stipulation? BTW, I quietly
> donated over 15% of the proceeds to certain individuals in the
> community which I thought were doing exceptional jobs.

Do you want a medal?

> The source code (.c and .h files) for my "SMTP SPF Filter" is about
> half the size of libspf2 (in bytes, not lines). The source code for
> the GUI that controls it ("SMTP SPF Filter MMC") is about a quarter
> the size of libspf2. So I guess all together its around 3/4 the size
> of libspf2. Oh, and I also ported libspf2 to Win32 and contributed
> that code back to the project. Since libspf is "so much smaller than
> libspf2", I'm guessing I've written more SPF related code than you.

Well if you want to compare cock sizes Michael, I'm the only individual
in here who has authored libraries for both SPF and SRS, and both in C.
I dare say your "tinkering" with Wayne's even puts your rod within
arguing distance.

> I worked 60+ hour weeks on it from April 25th until June 1st, 2004 and
> basically put all other consulting work on hold at that time. The
> actual code itself didn't take that long to write. The problem was
> that I had to use undocumented and barely documented APIs. Microsoft
> is required to expose these APIs by law, but they aren't really
> required to document them fully. So, it meant a lot of trial and
> error, debugging, and flat-out guessing about how to do things.

Again, do you need a medal or something? What exactly are you trying to
prove? That your opinion means something?

> People I don't even know have sent me e-mails saying that they didn't
> want to become part of this thread, but they thanked me for writing
> what they would have said. Personally, I'm still not sure whether
> entertaining this thread was worth it.

Amusingly enough I can say the same, only some individuals have even
taken the time to voice their opinion as to the loony nature of this
entire argument, and for that I thank them.

I am 100% in the right here whether or not anyone agrees that I'm
dragging this out into the open or not. There is no gray area, or "oh
gee I just dunno..." area. Grow up, the lot of you.

Having to read all of your pathetic attempts as justification is a bore
I wouldn't force upon my greatest enemy. Three wrongs don't make a
right, but it would fucking brilliant if the lot of you would search
deep within your selves for a human quality by the name of humility,
admit your CLEAR and BLATANT wrong doing, and simply "Do the right
thing" (tm).

Hell I'll even settle for a "fuck you here is your name back!".

"Screw you guys, I'm going home." - E. Cartman.

Good Day.

James

--
James Couzens,
Programmer
( ( (
((__)) __lib__ __SPF__ '. ___ .'
(00) (o o) (0~0) ' (> <) '
---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo---

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

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

James wrote:
> I dunno what to think of you. You've done a fair amount of damage your
> self by charging for your plugin, and I think this is absolutely
> shameful. SPF isn't supposed to be about making money, its supposed to
> be about promoting ANTI-FORGERY, I really believe you should just give
> it away. Its not like you really put much work into it, or am I
> mistaken in some way? (That may sound snarky, but it is not, its an
> honest question, as I am not overly familiar with the process of hooking
> a gui around a dll in windows).

Michael R. Brumm wrote:
> The plug-in is freeware. I sold it to a company under the agreement
> that they would also keep it freeware. Gee, do you think I could have
> gotten more money if I had not made this stipulation? BTW, I quietly
> donated over 15% of the proceeds to certain individuals in the
> community which I thought were doing exceptional jobs.

> The source code (.c and .h files) for my "SMTP SPF Filter" is about
> half the size of libspf2 (in bytes, not lines). The source code for
> the GUI that controls it ("SMTP SPF Filter MMC") is about a quarter
> the size of libspf2. So I guess all together its around 3/4 the size
> of libspf2. Oh, and I also ported libspf2 to Win32 and contributed
> that code back to the project. Since libspf is "so much smaller than
> libspf2", I'm guessing I've written more SPF related code than you.

> I worked 60+ hour weeks on it from April 25th until June 1st, 2004 and
> basically put all other consulting work on hold at that time. The
> actual code itself didn't take that long to write. The problem was
> that I had to use undocumented and barely documented APIs. Microsoft
> is required to expose these APIs by law, but they aren't really
> required to document them fully. So, it meant a lot of trial and
> error, debugging, and flat-out guessing about how to do things.

James wrote:
> Do you want a medal?

> Well if you want to compare cock sizes Michael, I'm the only individual
> in here who has authored libraries for both SPF and SRS, and both in C.
> I dare say your "tinkering" with Wayne's even puts your rod within
> arguing distance.

> Again, do you need a medal or something? What exactly are you trying to
> prove? That your opinion means something?

I was just answering your questions, correcting the mistakes in your original paragraph, and rebutting your insinuations that I am "about making money" and did not "really put much work into it". I guess if you didn't care to have an answer, then it really wasn't an honest question.

Michael R. Brumm

-------
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 Thu, 2004-07-29 at 05:23, Michael R. Brumm wrote:

> I was just answering your questions, correcting the mistakes in your
> original paragraph, and rebutting your insinuations that I am "about
> making money" and did not "really put much work into it". I guess if
> you didn't care to have an answer, then it really wasn't an honest
> question.

Well at least you get to the point this time. I was looking for an
answer, but the drivel of excuses you delivered through you last post
certainly wasn't.

I thought that you did a fine job with your exchange hook. However, the
fact that there is ZERO code available in typical windows fashion does
anyone any good. You've cleverly neutered the viable user base and
restricted them to a single vendor.

I find it somewhat comical you fail to respond to my comments on your
"library reasoning". Thats the typical response from the midwest camp.
Accuse, refute through inadequate means, and then skirt the issue hoping
it will either blow over or become a none-issue at some point.

Cheers,

James

--
James Couzens,
Programmer
( ( (
((__)) __lib__ __SPF__ '. ___ .'
(00) (o o) (0~0) ' (> <) '
---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo---

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

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

James wrote:
> I thought that you did a fine job with your exchange hook. However, the
> fact that there is ZERO code available in typical windows fashion does
> anyone any good. You've cleverly neutered the viable user base and
> restricted them to a single vendor.

I understand your point here, however I believe I achieved four goals:

1) Put an SPF filter on any Exchange/IIS server that installs GFI's MailEssentials for their anti-spam features. And, I'm sure GFI's marketing department will also advertise this feature. This should introduce many new people to SPF.

2) Provided Windows users with a commercial SPF product from a well recognized vendor that will provide maintenance, and technical support. This is what Windows users want. If they wanted open-source software, do you think they would be using Windows and Exchange?

3) Made Microsoft realize that they will now have commercial development partners competing (both with Microsoft and each other) for the SPF filter market on their Exchange/IIS products. It is basically a "get working on SPF/SRS support" slap in the face.

4) Helped port an SPF library (libspf2) to use native Win32 API calls, which should help both open-source MTAs that run on Windows, and help other vendors create their own event sinks for Exchange and IIS.

> I find it somewhat comical you fail to respond to my comments on your
> "library reasoning". Thats the typical response from the midwest camp.
> Accuse, refute through inadequate means, and then skirt the issue hoping
> it will either blow over or become a none-issue at some point.

I was hoping that someone else would help illustrate the problems with your accusations, because honestly it seems like a waste of effort and I'm nearing bedtime. But since you have launched yet another insinuation at me...

James wrote:
> Irregardless of the irrelevant material you just posted, its confusing.
> Why does Microsoft not tolerate "mikerowesoft.com" or "lindows" as
> names? Because they both share the an ability to misrepresent Microsoft
> in any fashion, irregardless if it could be positive or negative, its
> misleading to people, and that is why its wrong.

Michael R. Brumm wrote:
> Microsoft uses many strangle-hold legal tactics to prevent any
> competition in any way. Are you suggesting that you wish to follow
> their lead?
>
> In an egalitarian, open-source development community, there are many
> "libdns"s, "libsmtp"s, etc... (many not even differentiated
> by a number or author name). Obviously, the more successful ones are
> the ones that are better known and used.

James wrote:
> Perhaps I should use a different example, so you don't get so easily
> sidetracked. How many coffee houses do you see out there named
> Starlucks? or burger joints named McRonalds? or perhaps BugerQueen?

Are we talking about private industries that fight tooth and nail to make money, or an egalitarian open-source development community? I don't see why you constantly employ the "tooth and nail" anti-competitive tactics when we are all trying to work toward the same ends.

James wrote:
> You see this?
>
> -rw-r--r-- 1 root root 732294 Apr 27 04:42 libxml.a
> -rwxr-xr-x 1 root root 594232 Apr 27 04:42 libxml.so.1.8.17
>
> -rw-r--r-- 1 root root 1449288 Apr 30 12:05 libxml2.a
> -rwxr-xr-x 1 root root 1129432 Apr 30 12:05 libxml2.so.2.6.9
>
> I'll never be able to do that with my library. GREAT JOB GUYS.

Let's make sure everyone is clear about this. Your argument cannot validly be based on a technical problem with the namespace. If you have the opinion that names should not be similar, then that is valid (any opinion can be valid), but there is no technical problem.

libspf can do the following:

libspf.a
libspf.so.1.8.17

libspf-2.a
libspf-2.so.2.6.9

libspf2 can do the following:

libspf2.a
libspf2.so.1.8.17

libspf2-2.a
libspf2-2.so.2.6.9

James wrote:
> A directory of freely available C libraries:
> http://directory.fsf.org/libs/c/

It is not entirely surprising that this site does not list similar and/or conflicting library names. I'm sure you can find a ton of sites that don't. I can find sites that only refer to libspf, and I can also find sites that only refer to libspf2. It doesn't prove anything.

Michael R. Brumm

-------
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 Thu, 2004-07-29 at 07:49, Michael R. Brumm wrote:

> I understand your point here, however I believe I achieved four goals:

<!- snip ->

I agree with all four of your goals, they are all advantageous, and of
benefit. That being said, not having made the code available, people
still have to PAY to implement SPF. Although YES you have aided the SPF
community, but in the manner in which you went about doing it, you have
also hurt the SPF community. Had you given the code out, you would find
that people would:

> 1) Put an SPF filter on any Exchange/IIS server that installs GFI's
> MailEssentials for their anti-spam features. And, I'm sure GFI's
> marketing department will also advertise this feature. This should
> introduce many new people to SPF.

Yep GFI would still do that

> 2) Provided Windows users with a commercial SPF product from a well
> recognized vendor that will provide maintenance, and technical
> support. This is what Windows users want. If they wanted open-source
> software, do you think they would be using Windows and Exchange?

Yep, they would still get that.

> 3) Made Microsoft realize that they will now have commercial
> development partners competing (both with Microsoft and each other)
> for the SPF filter market on their Exchange/IIS products. It is
> basically a "get working on SPF/SRS support" slap in the face.

Yep, MS would get this point, only MUCH quicker, and it wouldn't be a
bitch slap.

> 4) Helped port an SPF library (libspf2) to use native Win32 API calls,
> which should help both open-source MTAs that run on Windows, and help
> other vendors create their own event sinks for Exchange and IIS.

Yep, that still would have taken place.

5) Michael got $$$$ paid $$$$ (and in turn Wayne got paid)

No, I guess you wouldn't have gotten paid :( But you would see win32
support MUCH farther along then it is, and further circumvent any
further stupidity on the part of MS.

> I was hoping that someone else would help illustrate the problems with
> your accusations, because honestly it seems like a waste of effort and
> I'm nearing bedtime. But since you have launched yet another
> insinuation at me...

Why would someone else have to defend your statements?

> libspf can do the following:
>
> libspf.a
> libspf.so.1.8.17
>
> libspf-2.a
> libspf-2.so.2.6.9
>
> libspf2 can do the following:
>
> libspf2.a
> libspf2.so.1.8.171) Put an SPF filter on any Exchange/IIS server that installs GFI's MailEssentials for their anti-spam features. And, I'm sure GFI's marketing department will also advertise this feature. This should introduce many new people to SPF.

2) Provided Windows users with a commercial SPF product from a well
recognized vendor that will provide maintenance, and technical support.
This is what Windows users want. If they wanted open-source software, do
you think they would be using Windows and Exchange?

3) Made Microsoft realize that they will now have commercial development
partners competing (both with Microsoft and each other) for the SPF
filter market on their Exchange/IIS products. It is basically a "get
working on SPF/SRS support" slap in the face.

4) Helped port an SPF library (libspf2) to use native Win32 API calls,
which should help both open-source MTAs that run on Windows, and help
other vendors create their own event sinks for Exchange and IIS.
>
> libspf2-2.a
> libspf2-2.so.2.6.9

Yes, that is possible, No I won't do it. Why? Because its CONFUSING
as hell. I take pride in the level of organization and clarity that I
feel I bring to my code and the projects that are related to it. I'm
not going to change the way I do things so that some selfish individual
can get his way, especially not to actually contribute to something that
will contradict the manner in which I develop software -- please note
that the naming conventions that I conform to are industry sanctioned
both in and out of OpenSource.

> It is not entirely surprising that this site does not list similar
> and/or conflicting library names. I'm sure you can find a ton of sites
> that don't. I can find sites that only refer to libspf, and I can also
> find sites that only refer to libspf2. It doesn't prove anything.

Of course its not surprising, because its a list of WELL known
software. This illustrates my point which is that the behaviour being
exhibited by Wayne is wrong, and in stark contrast to standard
practise. I will not deny that you could probably find some other
asshat out there who is doing the same thing that Wayne is, but that
doesn't make it right, or not make them an ass.

Michael, I find your logic infuriating! I respect the work that you
have done, but I have a very hard time respecting your attempted defence
of Wayne's actions. You try so very hard to take something thats not
qualified to represent Wayne's actions in a positive manner and fail
miserably. You _KNOW_ as Wayne does, full well that what has taken
place is _WELL_ outside of the realm of acceptable behaviour.

Wayne should be acting in accordance with the standards that are set out
not only by the Open-Source community but by major software corporations
the world over, as opposed to intentionally causing all of this
confusion. You nor anyone else can deny the stupidity and confusion
being caused. Why don't you stop trying to defend it and candy coat
it?

Just because I don't have millions of dollars to trademark something,
and to sue Wayne for his flagrant defiance of standard practise, does
that mean that nothing should be done about it? I think that you,
Wayne, Shevek, and others should dwell on that for a while.

I'm not asking anything unreasonable, and I'm offering to aide in this
request by offering free file hosting of related site and files, in
addition to purchasing a new domain name.

Cheers,

James

--
James Couzens,
Programmer
( ( (
((__)) __lib__ __SPF__ '. ___ .'
(00) (o o) (0~0) ' (> <) '
---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo---

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

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