----- Original Message -----
From: "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net>
To: <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Tuesday, April 06, 2004 12:06 PM
Subject: Problem, System complexity -> Solution complexity
Revelation.
...
When dealing with a complex problem, in a complex system, it is just
too darned easy to create a complex, baroque and ultimately useless
solution. The way to fight against that outcome is to look for small,
incremental steps and make sure we understand them.
Huh? Divide and conquer rings a bell?
It has always been a way you solve complex solutions and a good experienced
system/software engineer (like myself) understoods the "black box" model in
addressing problems like in SMTP.
What I've been saying since day one and quite honestly, I have been doing so
keeping you in mind, with your desire for "SMTP compatibility," if that we
need to address the Functional Specifications first - the relaxed provisions
in the functional specifications. Once that is "fixed", the technical
specifications and implementations will follow.
In short, vendors can not provide technical enforcement "logic" without
being labled "broken or non-compatible" when the functional specification do
not allow for enforcement logic to be developed. Its that simple. What
develops in an enviroment where there is weak, ambiguious functional
specifications is a "fuzzy" unworkable, complexed multiple and conflictive
solutions.
This is a very simple problem and it begins with the spammer exploition of
the weak anonymous access provisions in SMTP. The solution is quite
simple:
1) If you want SMTP compatibility, we have no choice by to enforce the
HELO/EHLO, MAIL FROM.
2) Otherwise, we need to change SMTP to offer new client/server handshake
authentication phase ala PPP.
What's not to understand here?
Of course, I don't know what I'm talking about. I must be speaking without
knowledge. I just been writing mail and hosting software since the early
80's. Means nothing of course. On a personal level, I take fault here
because I was new to this "IETF" process. I have no made "friends." Geez,
banned from ASRG? How silly is that!? I'm not proud of that as I have never
made enemies with people like many of the IETF people has shown my way. I
guess I stepped on a few toes. Nonetheless, what has been become painfully
obvious, it really doesn't matter what you think unless a certain core of
people "see" the problem in the first place. That's fine, but in the mean
time, I can't wait for this group to come to an obvious conclusion and if
you noticed, I don't think you will see other vendors waiting either!
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
It think that the paradigm we should be taking for dealing with spam
is to distinguish between:
Components -- small units of functionality
Mechanism -- Collections of components that form a whole capability
for doing something useful in the problem space.
Policy -- Rules for determining use of the mechanism
Service -- Mechanisms and policies combined to achieve something
useful in solving the problem.
This sounds pretty cumbersome, but the dangers of attacking all these
at once are confusion in the design and, ultimately, a solution that
don't get used or don't work. By separating them, we must discuss and
understand them _separately_. We must develop consensus on each,
without the distractions of the others.
Thus we build a total service using pieces that we understand and
agree on, rather than essentially having to wave our hand over a whole
service proposal and do a single thumbs-up or thumbs-down popularity
contest.
For example, if we are going to do a DNS-based registration scheme,
then we should define it generically, so itt can be used for different
things. Then we should define a particular use for it. This is what
Pete is suggesting.
I agree sufficiently to be submitting a revised version of my own
proposal that separates the underlying components from its application
into a mechanism for MTA.Helo checking. (The policy of what to do with
that checking becomes yet-another discussion.)
We can then discuss the mechanics and implications of the underlying
components, to make sure their benefits and problems are explicit.
The new draft of my proposal contains examples of this. I'll post it
shortly.
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>