----- Original Message -----
From: "Jonathan Gardner" <jonagard(_at_)amazon(_dot_)com>
I've finally got something to say. I'm sorry I've been out of the loop for
so
long but that's what happens.
....
Hi Jonathan,
I think this is all good. Although there were many decisions (and I think
it continues today) that perpetuated many of the problems, unfortunately, we
might be spitting against a wind that is being strategically orchestrated by
a set of individuals, which unfortunately, are a) very vocal or b) have the
ears of IETF/IAB people currently in charge.
In my view, much of the issues were obvious from day 1:
1) Meng allowed Microsoft to basically patent SENDERID without any
prior art references which is required by the USPTO. This was
the #1 mistake. On the bright side, if push comes to shove,
this intentional neglect of properly describing prior art is
easily proven and will undoubtedly cause the patent to be
throw out, including possible a fine levied against Microsoft.
This is a BIG no-no (intentional neglect of prior art references)
in patent cases.
2) Meng (and others) played a marketing and promotional role in
SenderID/PRA.
3) SPF and SENDERID/PRA were technically incompatible.
4) Never mind the PRA issue or the fact it is technically flawed,
SPF is a 821 concept, SENDERID/PRA is a 822 PAYLOAD concept.
When it comes to a payload solution, you are going to get a lot
of resistance, especially, when its "pay off" is extremely low.
There is more, but in short, these four basic facts about the situation was
an obvious recipe for a problem. It wasn't like some people (including
myself) where not highlighting these issues for a very long time. The
problem wasn't getting Microsoft involved or getting their initial support,
the problem was SPF give away too much in the name of pig backing on the
gorilla's "marketing" power. Meng admitted it himself that he wanted to use
Microsoft support to promote SPF even if there were some problems.
Well, those problems were not squared away and he continue to support
SENDERID while in the same breath at times, "demote" SPF.
In short, you can't have the "father of SPF" go against his own creation and
expect there not be problems down the road. It just doesn't happen like
that. The father of a invention has to be the #1 promoter and defender.
So with that said? Where you do go from here?
1) The SPF council (and MENG) should get a lawyer to write up a PATENT
DISPUTE to report the Intentional Neglect of prior art references in the
SENDERID/PRA patents. This PATENT DISPUTE has to get on record. It might
be enough to nullify the patent application. This should be done before the
patent is finally issued. I know I have mentioned this a few times in
various forums, and if Microsoft was lurking and if they are smart they
would of re-file or add prior art claims by now. Microsoft does watch the
forums.
2) Meng, Julian et al, need to immediately put a HALT to SENDERID/PRA
promotion until the issues are worked out.
3) SPF needs a strong sponsor to finally get all this WEB SITE, SUPPORT
organization finally once and for all. Properly a non-profit corporation
should be started to help start fund raising and attract commercial vendor
membership. This needs to be done for two reasons:
- Build confidence in the Industry
- Remove the "Mickey mouse" operation and "OPEN SOFTWARE" negative
connotations AKA build a professional presence.
I can't tell you how many times I have considering pulling SPF support
simply based on this "negative" presence SPF has.
On the technical side:
4) Don't harp or depend on IETF endorsement. Possibly new sets of
documentation are needed:
- Functional Specs - Overview of technology (How it works?)
- Operational Specs - Targeted for admin/operators/ISP audience
- Technical Specs - Targeted for Developer audience
- Writing Extensions - Targeted for Developer audience
- Integrating SPF with other solutions (Both developer/Admin)
5) Begin the following new projects:
- Make sure the language is ready for extensions
- Feedback and reporting ideas
- Defining Rejection Policies
- Defining Reputation Hooks
Overall, SPF needs to not worry about the IETF and its close nit of certain
partisanship people who are actively, vocally and adamantly against SPF and
will say practically anything negative against it regardless of its
positives and its obvious large usage and support in the industry. Too many
conflicting disciplines and attitudes. Based on what I seen so far, nothing
will ever get accomplished in there. Just consider SPF got this far for
the EXACT reason that it by-passed the IETF process to being with. Getting
their blessing now probably isn't going to happen - not when you have Dave
C, Doug O, Keith M, John L and Phillip H and others pushing againt it. And
now that DKIM is getting attention, well, you can forget about any kind of
SPF support from this crew of people.
Anyway, the rest of the world are not stupid. We don't all depend on the
IETF, if we did, we would not be here today. People can read inbetween and
behind the double talk and the rhetoric. What most people typically look
for is confidence and a professional organized supported system, that it has
a PAYOFF to work and has a continued future.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com