----- Original Message -----
From: <Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu>
To: "Hector Santos" <winserver(_dot_)support(_at_)winserver(_dot_)com>
Cc: <ietf-smtp(_at_)imc(_dot_)org>
Sent: Saturday, January 24, 2004 3:36 AM
Subject: Re: I-D ACTION:draft-klensin-email-envelope-00.txt
You're the one who brought up "closed mind attitude".
Its true! <g>
You're also the one who asserted "You guys need to listen and begin
opening your minds", without considering that maybe our minds *are*
opened, and we're willing to listen to new ideas, but *no new ideas
are forthcoming*. More about that later.
In my view, the reason for this is that the functional specification is
inherently restrictive and this is what I meant
by "opening your minds" because maybe then some legit effort can begin. I
don't think I am off based the general consensus viewpoint most often cited
about the IETF is that it is a closed knit group of vets where proposal for
change is philosophically, militantly and fundamentally not welcome. :-)
to the people who may read the list archives in the future, trying
to figure out why *their* brilliant pet proposal got shot down...
People will read this tone, the negative "brilliant pet proposal"
description in the archives and they will ASSUME a "closed minded attitude"
and become more resistance to participate because the tone ridicules them.
OK, You tell me. What do *you* tell one of your engineers when
they come in with the *same* idea that 8 other engineers have
suggested, and this latest one hasn't done anything about the
fatal flaw you already pointed out to 8 others?
Since you ask :-) Might be off base, you would probably say:
"Be there, done that. Don't need to go there."
The fellow will be less encourage to provide future input because of your
unintentional, no harm intended, closed minded
intimidation.
Me?
I would listen first and not oppress creativity by presuming the idea is the
"same." It may sound and inevitably when all things considered, be the
same, but I will not dampen and kill the realistic possibility this guy
might "see something" the other 8 did not. In short, play dumb and allow
him to talk.
"Interesting Tom. You know some research was already done
in this area. You have a slightly different twist in this
particular area. Why not run it by so and so...."
If your design research philosophy prevailed, technological innovation would
of been oppressed a long time ago, probably
explaining why SMTP is at where it is now - stalled! It is not uncommon to
have different groups of engineers be asked to tackle the same problem with
the primary purpose of not allowing a singular thought process to prevail.
Exactly. Unfortunately, some of the "historical perspectives" the
veterans have are:
0) Most of the following is oriented towards anti-spam stuff, mostly
because
that's the single biggest unsolved problem in the SMTP world.
Agreed. So what are we doing about it?
1) Most "new ideas" are re-inventions of ideas already proposed anywhere
from
months to decades before.
So what? Allow the possibility of a new possible view point. You simply
never know.
2) Most of said ideas have a fatal flaw. If they didn't, we'd probably
have deployed them the *first* time they were suggested.
And the fatality of these ideas are based on a flawed functional
specification. When the technical design criteria for any new SMTP
inventions must be backward compatible, all new ideas are inherently flawed.
When the specs has it written in stone that "it is flawed" from a security
standpoint, then makes no attempt to address it, all ideas are lost. Why
bother?
This is the only issue I have with the IETF - this viewpoint needs to change
and by that I mean, once again, the "enforcement" *SHOULD* be allowed,
otherwise the idea is weak right out of the starting cage.
3) There's been a *lot* of ideas with fatal flaws. See Vernon Schryver's
intro to the subject: http://www.rhyolite.com/anti-spam/you-might-be.html
And keep in mind that list is not exhaustive - it's merely the anti-spam
ideas Vernon has seen *so* many times he got annoyed.
I've seen this in the past. Silly, childish, again, all based on the
fundamental flaws of the specs prohibiting any new idea to
even possibly have a chance to be researched, be adopted or enforced! All
ideas are flawed because none are technically enforceable. Most ideas
addressing anti-spam are flawed because the specs has it written in stone
that any attempt to validate or control access is technically flawed and
btw, technical not compliant. I don't know about you, but there is
something wrong with that picture.
Also, my approach to the anti-spam problem at the SMTP level is not to
interpret mail-content but by applying new anonymous access control
restrictions at the protocol level independent of what the mail-content
might really be - good or bad, if the sender is not "compliant," no
transaction - period.
4) There's still spam. Why? Because none of *us* are clever enough
to come up with an idea that doesn't get nailed by at least one point
on Vernon's list either. As a result, the most productive use of our
time is to point everybody at that list or some similar, and have them
self-evaluate their proposal, and let us know if they think they're
really on to something new.
Again, you point out what I am talking about. Assuming Vernon's list has any
validity, why is failing 1 point considered a complete failure? And again,
its all based on the fundamental flaws of the specs. So until you see this,
there is NO going to be any progress whatsoever with IETF vets. <g>
Not to spur up another debate, I don't have a spam problem any more. That
problem has been solved. Yet, I might see 1 spam might sneak in out of 3000+
attempts per day. I think that is pretty good. I don't see that as a
failure, and yes, I am using a CBV as the heart of the suite of anti-spam
methods using a basic PRESUMPTION the return path must be verifiable. So for
us, SPAM is a thing of the past.
If you disagree with that presumption, and are not willing to see that there
is a conflict with CAN-SPAM which mandates it must be valid and that the
spammers exploit this to the maximum extent, then maybe you can see why I
say you need to open your minds more.
If you disagree with the CBV concept for scalability issues, and are not
willing to "research" an optimal validation concept
(which implies you first need to agree that it is enforceable), then again,
maybe you can see why I say you need to open your minds more.
The problem is not the SMTP protocol. The problem is the functional
specification. It conflicts with the realities of
today's industry problems. It restrict innovation. It restricts enforcement.
It is the REASON the industry problems exist in the
first place to the extent of a $8 Billion dollar industry wide price tag.
What allows this happen? The smtp protocol or the functional specifications
that prohibits innovation?
Spammers love you because it is the latter that allows it to happen. They
are laughing silly all the way to the bank
exploiting and abusing our networks and machines at the same time.
5) Never try to read too much into the postings of anybody
who posts at 3:30AM who isn't actually employed as third-shift
personnel. :)
Point well taken. <g>
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com