----- Original Message -----
From: "Chris Haynes" <chris(_at_)harvington(_dot_)org(_dot_)uk>
Sent: Wednesday, October 27, 2004 5:51 AM
Subject: [spf-discuss] Development - Marketing parallelism
What I think is happening is a natural, common aspect of the growth of any
technically-complex product - the product and its marketing need to split
into
parallel paths.
...
Has anyone got any pointers to how other open, high-visibility projects
have
approached this problem? Apache?? Mozilla?? Open-Office??
Chris,
Only one problem with this: SPF isn't a product. SPF is just 0.001% of a
total solution. It is a specification. It is a PLUG IN at best.
I understand what you are saying, but that is part of the problem - they are
viewing this as a Product more than a specification, that you get done and
move on. Can you imagine if SMTP was a Product? or RFC 2822 was a Product?
Now, you can get the SPF specification done and then move on to augment a
higher level solution as a "product" that Meng can sell for example. But
SPF is not such a "product" itself and the moment it does, seriously
problems will emerge.
The problem as I see it is the mix and conflictive disciplines. Technical
people need to work it out. It hasn' t been worked out because you have
non-technical people dictating its specifications. Let I said a few times,
is it has two major issues that don't help it get off the ground to a
majority acceptance and quick adoption.
- Helo checking
- Relax Provisions
I say that because I have an extremely sick resume in project R&D, product
R&D, Technical Sales and marketing as well.
The above are easy "no brainer" issues to satisfy at all levels, technically
and from a marketing standpoint. Unfortunately, they remain "thorns on the
side" until they are resolved. The problem? It might be too late.
I could care less for the other moronic issues going on here. Multiple
Drafts, Wayne vs Meng (where that came from?) "Product Marketing Surveys,"
etc, etc.
As far as I am concern SenderID/PRA is a dead horse and SPF going after it
is a major mistake. You don't need to merge the two. Implementers will
decide how to put suites of technology together like we have. No
specification is going to dictate how we apply our TMS <tm> (Transaction
Management System).
Implementing SenderID/PRA is so costly, MS is going to have to PAY US to
change our code (and pay for new product liability insurance) to add
SenderID/PRA support. If Billy Gates thinks that they can force the issue
via marketing pressures (see their FTC Email Authentication Summit paper)
well, I see major Anti-Trust issues brewing.
If SenderID/PRA was a reliable technology, that would be one thing, but it
isn't so anyone using it is just doing so for Marketing reasons - case in
point? The AOL flip flop!
There was nothing technical different in MS's new draft - I don't see it.
Hence AOL change in mind has nothing to do with the technical merits and
strictly a marketing posturing getting themselves ready for the FTC Summit
in a few weeks.
The FTC Summit will help resolve many incomplete issues or directions.
Unfortunately, it will be MS's voice that will be heard the most. I just
hope the FTC hears and takes serious all the public comments made to them,
including ours.
--- Hector