Dear Hector,
I understand your frustration and I am sure that it is shared by many
others here and on the rest of the Internet. However, the developer's
perspective is not what is needed here, ....
Its not?
you also need the designer's perspective.
I really hate to get into the semantics game. I'm lumping "developer" to
mean a vendor of a software product with both project and product
development experience What's a developer to you? A programmer who takes
specifications from a software engineer? I don't wish to give you the
impression of cutting myself short, but FWIW, I'm a college educated
professionally trained Chemical Engineer who can't get any more "systems
design oriented" then most other disciplines. I have over 25+ plus years of
computer system or software design and integration experience in both R&D
and product development for "systems" as complex as Nuclear Power Plant
control systems to as simple as MAIL, to name just a few of the hundreds of
projects I've been involved with. I've project managed systems designed
from as low 5M to 50M projects. So I don't speak as just a "programmer."
I'm a "systems" guy that is proposing a system that does take into account
aspect from the consumer to the operator as well as the operability of the
network with compatibility being a very important aspect of it as well.
The designer looks at the overall Internet infrastructure and the spam
problem as related to that infrastructure. While the developer jumps to
writing code and implementing solutions, the designer takes his time
looking at the overall structure and how everything else might affected
by the code to be written.
And it shouldn't be any other way. Yet, a true engineer has the vision of
the recognize problems and the steps needed to be taken. The better
engineer can propose a solution that will help in the transition. Our
intranet system is one of the more sophiscated mail/file "client/server
systems" around. Migration issues from upgrade to upgrade is very
important.
We cannot mandate sweeping changes, we cannot
change the SMTP protocol overnight, we cannot force millions of people
and companies switch over to a "perfect" system at the tune of billions
of dollars, euros, rupees, etc.
I am not proposing such a mandate. It would be a transition as any "Good
Engineer" would recognize as being suggested.
We are
responsible to all of the Internet users on this planet, we maintain the
Internet and keep it operating. This requires very careful analysis of
any changes to the underlying protocols and standards on it.
There is a reason why no specific proposals are being concentrated on -
we do not have any way to evaluate them. The technical considerations
document
(http://www.ietf.org/internet-drafts/draft-crocker-spam-techconsider-02.txt)
outlines many of the issues that will face us in this analysis.
I'm not advocating your elimination nor your reason for living, nor your
responsibilities, nor the need to do this overall analysis. However, I am
advocating the recognization that the problem is really quite simple which
is 100% based on outdated SMTP specifications, in addition for the
recognization that any change regardless of what is proposed will required a
change at the software level. If that is the case, then borrowing a quality
control terminology, lets "Get it right, the first time!" It doesn't
take a "developers" with 1 or 2 years in the market to see this. If what
is being proposed is going to require a change at the software level, if you
want people to follow it, then it better be RIGHT, the first time.
However,
most developers want to jump straight to code instead of analyzing the
impact of it on others.
This is exactly what I expected to hear from the administrator. You really
don't give "developers" the benefit do you? I have thousands of customers
world wide. Every new change and feature goes to thru extensive design
consideration cycles. Every change is done with the UTMOST consideration
possible for usefulness as well as compatibility.
That is why so many efforts must be concentrated
on analyzing the problem because that is necessary for the analysis of
proposals.
The analyze of the problem has already been done - SPAMMERS have
unrestricted access to SMTP systems because the specs allow it so. You can
come up with 1 million kludges. Ultimately, it boils down to client access
to the system.
Therefore, I would like to suggest that our concentration should be on
getting some documents out the door on the problem of spam, and how to
analyze and evaluate solutions. The technical considerations document,
the requirements document, the inventory of problems, the analysis of
spam, the consent framework, the proposal guidelines, the evaluation
model, etc. all of these need volunteers. If you want to kill the
problem, that this analysis must be performed. If you want an overnight
solution - stop looking - it cannot be found.
Can you prove that there isn't a solution? I don't need to look any further.
I already now what the solution is, and no, it is not based on overnight
thought process but many years of operational and practical experience.
Didn't you read anything I posted? It doesn't sound like it. Anyway,
this is exactly what I was afraid of. This is a big was of time. Good
developers, no, excuse me, "designers" hanging around here worth their
salt knows exactly what I am talking about. Lets stop pussying footing
around and get a new SMTP specification worked out that solves the problem
yet offers a transition concept.
If you would like to continue this conversation, please email me off-list.
No. Why? Keep it open. What are you afraid of? Anarchy? I don't want
to talk to one person, an administrator is going to blew me off anyway. I
want to talk to the community.
Listen, I'm well experience enough to look at all these proposals, using
your +/- check off list and tell you that the ultimate solution is a
restriction/authorization concept. Do you design, develop and market a
MAIL system? I don't know about you, but I do. I know what the problem is
and I know what the solution is. I know what my customers are looking for
and yet at the same time, I know how important "standards and compatibility"
means.
Hector Santos
WINSERVER "Wildcat! Interactive Net Server"
support: http://www.winserver.com
sales: http://www.santronics.com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg