----- Original Message -----
To: "Hector Santos" <winserver(_dot_)support(_at_)winserver(_dot_)com>
Sent: Friday, January 23, 2004 10:24 PM
Subject: Re: I-D ACTION:draft-klensin-email-envelope-00.txt
What is often mistaken as "old guru closed mind attitude" is the
experience to be able to tell that *any* proposal in category X
is doomed to failure unless problems A, B, and C are addressed,
and any proposal in Y has almost-certain fatal flaws D and E, and
May I ask, why do you assume I lack system design or system wide engineering
integration, design impact, understanding , capability or experience?
What is becoming quite clear to me, it seem to have a fundamentally flawed
assumption about me. I am trying to be nice. I do not make the assumption
you or anyone else here is not competent.
Another common error is failing to understand the realities of
scaling and deployment.
Yet another fundamentally flawed assumption. Why do you assume I lack basic
understanding in high end product operations?
It would take me a short afternoon to put
something up to test, understanding that it was beta-quality
Again, why do you presume I lack this understanding? Do you an exclusive
copyright on this concept?
Getting everybody in my department moved is a much
bigger challenge, and migrating 60K users is a year-long
proposition, and migrating the millions of users of an AOL or
Hotmail is a daunting issue indeed. (Hint - how many extra
first-line help desk people would AOL need to hire, and what
would the price be for that?
Sure, nothing but a sound migration plan can't address. But again, why do
you assume I don't understand this? I said nothing to indicate otherwise.
Is the cost of the migration more than their current anti-spam costs, or
Maybe, maybe not. But again, was there anything specific I said to suggest
I don't understand this concept?
Don't forget to include burning 100M new coaster^H^H^H^H^H CD's with 'AOL
now with new anti-spam' on it).
Again, what was it did I said to suggest I don't understand this
TV ads. Lots of them. You'll need them. If you don't
understand why, don't bother commenting until you do. ;)
or that I don't understand product marketing?
Oh, and don't forget that you're not allowed to break anybody's
connectivity at any point along the line. The NCP->IP migration
was bad enough wnen there were only several hundred hosts.
One bad experience should not block your vision.
We'll never get to do that again. If you have half the users migrated
to SMTP-bis and half are still on SMTP-classic, they *will* have
to be able to communicate, or you *will* be fired.
I'm the boss so it can't happen! <g> However, I don't mind saying this
tangential ad nauseum reading is something I look for when considering a new
job applicant. :-) Having insight and hindsight is one thing. Allowing it
block progress or vision including the discussion of the possibility is
So for instance, the previous paragraph is why *any* proposal
that doesn't provide benefit until 98% or so of the net has
deployed it is doomed to fail unless you give a *really* good
explanation of why 98% of the people should deploy it when it
isn't going to give them any benefit if 3% of the OTHER people
Well, I used pareto's principle (look it up) when it comes to most aspects
in my natural, everyday decision making process. Most successful people do
and with great success in the end result.
With that said, I believe there are some fundamental flawed assumptions in
your particular statement above:
1) the flawed assumption a proposed consideration, concept or idea is not a
good idea to begin with at any level minimizing possibility or consideration
for implementation, and
2) the flawed assumption a proposed consideration, concept or idea is not a
well written and does not include a sound acceptance and deployment plan,
i.e., the author did a terrible job, and
3) the fundamental flawed assumption that a proposed consideration, concept
or idea will not be (cost) effective or beneficial unless it is deployed by
a majority, and
4) finally, the fundamental flawed assumption that a proposed consideration,
concept or idea can not be fine tuned over time to meet whatever benefits
sought to maximize acceptability and deployment.
FWIW, I honestly hate stooping to this level, but I feel you have the
wrong impressive about me. I am getting the impression that you (and
others) honestly think I'm a "dummy," lack product design, development and
deployment experience and insight and overall feel there is no merit or
reason in my statements. So excuse me if I may provide you a better insight
about me. I am a chemical engineer by trade with 28+ years software/product
design/engineering/production experience that will make most people puke.
Since 84, I have been very active in designing, development and supporting
mail based products. I helped pioneered the off-line mail market, certainly
the first to mass market the concept during these early days. My company
currently serves a relatively small market of over 100,000 customers using
one or more of our intranet, dial-up, and/or file/mail server hosting
product lines. Sure, probably small potatoes in your mind, but its big
enough for us mind you. It keeps us busy and more importantly, debt free and
profitably. I like to think our competitive advantage is superior design
and responsive customer support. My long standing strong ethical
engineering principle and strategy for the company is simple: Minimize your
bugs, offer robust, fast, no compromising technical design concepts and your
customer satisfaction is maximized and your customer support issues,
overhead and cost is minimized. As a small company, this is a must. We
are #1 in a particular fortune 500 market niche offering a sound time-tested
engineered integrated client/server design framework. Yes, SMTP (the mail
system) is not our main niche, but its among our highest growth areas.
Based on shared former Lotus Notes and MS Exchange customer testimonies,
our mail system is considered very worthy, very scalable and without a
doubt, definitely considered the fastest. Our mail server which supports
various gateways such as Fidonet (Netmail and Echo Mail), Internet (Email
and News) and other mail networks such as QWK/OPX/RIME networks was
originally designed from the ground up for high volume satellite based feeds
and ISP mail hosting Processing 100-155 messages/sec was a design
requirement. Yada, yada, yada, yada... again I'm embarrassed to stoop to
this need, but you make sound like I am some "young punk." <g>.
All I am saying it is a mistake I lack reason, knowledge or insight in my
statements. I appreciate the experience and historical IETF perspectives
shared by your and other IETF veterans here . But I will not allow views I
may not agree with block my own creativity in problem solving. It has worked
for me for many years. I came here with an open mind with a desire to have
a solid professional technical discussion that improves or addresses the
major current industry issues we are facing. Honestly, I would love to
meet the authors of all the SMTP packages. So yes, I don't mind saying
maybe I have a selfish focus here. I am a commercial developer which I
sincerely hope you and others here do not hold against me. This focus
should not suggest to you I lack insight when it comes to new ideas.. I am
100% aware and understand design implementation issues and yes, I
understand resistance for change. I agree 100% that unless an SMTP
altering idea has a major benefit, it *MAY* not (not MUST not) be worth
considering. My goal is to help if I can and that includes being open