(Burning my third (and last) post for the day...)
In <40F5A896(_dot_)3080706(_at_)moongroup(_dot_)com> Chuck Mead
<csm(_at_)moongroup(_dot_)com> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bitten by the Reply-to! I sent this directly to Harry instead of the
list which was my intent.
Harry Katz wrote:
| On Wednesday, July 14, 2004 10:54 AM, Hector Santos wrote:
|
|
|>I second your concerns. This is completely disturbing. Not
|>only do I think the proposals are faulty, will incur a high
|>degree of compatibility issues, will translates to a high
|>revamping and resign cost, I now have to worry about
|>fighting what would be prior art issues anyway?
|>
|>No, there is got to be a better answer to all this. This is
|>fast becoming a "MICROSOFT" only solution and Bill Gates
|>recent quote saying using security as a "Strategic
|>Competitive Advantage" might come back to bite him in the
|>anti-trust area.
|>
|
|
| First, please read Ted Hardie's posting about our IP filing with respect
| to the original Caller ID specification from which Sender ID is derived.
Sender ID is derived only from Caller-ID? Gee... there's a concept...
Where did SPF come from then?
Sender-ID is a merger of SPf and Caller-ID, therefore Sender-ID is
dirived from both. It also has news stuff, like the SUBMITTER ESMTP
idea, thrown in.
| Second, to suggest that this is becoming a Microsoft only solution is
| outrageous, abusrd and without any basis in fact!
For my part I don't claim that...
For my part I don't claim that either. I am concerned that some
important MTAs/Spamfilters may be locked out of implementing
Sender-ID.
I suspect that if someone would simply clarify it we'd likely be
satisfied ....
Yes, I think this is the point...
... as I strongly believe what we've been discussing is *NOT*
Called-ID which, consequently, kicks the CID RAND restriction to the
curb doesn't it?
... but, as I mention above, the Caller-ID RAND/Z license still
applies to Sender-ID.
-wayne