If its more than 25
years covering design, development and marketing with every form of
mail software from MUA to mid ware to hosting, then by gawd, I don't
know anything and you are far better than me.
If you've worked in this field for 25 years and still don't understand
layering, maybe you should try working on something simpler.
I ask the QUESTION hopefully to get an intelligent discussion going
You seem to think that an intelligent discussion is one that reinforces
your presumptions, and that being told that your presumptions are wrong
is an inherent sign of a lack of intelligence. Maybe you should re-
evaluate your idea of what intelligence is.
If you want to build an SMTP server that does filtering - knock yourself
out. If you want to standardize such a practice, you need to explain
why your approach will actually solve the problem when applied on a
large scale, and do so with less complexity/cost than other approaches,
and why it makes sense in the long term rather than just as a short-term
hack.
Why, after all, is this SMTP's problem? Why isn't it the OS vendor's
responsibility to build systems that are not easily compromised? Why
isn't it the application vendor's responsibility to build application
data formats that cannot convey viruses? Why isn't it the user's
responsibility to choose OSes and apps that are safe, or to avoid
launching apps on questionable data that was received from over the net?
It might be that things work best when there is a balance of
responsibility, when each party makes a reasonable effort to keep from
contributing to the problem. It's reasonable for operating systems to
have "permissions" including "execute permission" that is not set by
default whenever a file is created. It's reasonable for applications to
expect that they will be exposed to data created by malicious parties
and to be constructed to avoid causing harm to the host system and data
when that happens. And it's reasonable to expect users to take some
care in what OS and apps they install on their system and what they
do with data that they receive from questionable sources. It's probably
reasonable to expect SMTP to keep better track of where messages came
from and who sent them (for some meaning of "where" and "who").
What is probably not reasonable is to expect an unrelated part of the
system - like SMTP - to be smarter about applications and their data
formats than the parts of the system that deal directly with these
things.
Keith, with all due respect, you seem to have a fundamental flawed
premise about new IETF participants having little experience and
young, I am not making that up. You said it yourself in a 2001
article:
http://lists.w3.org/Archives/Public/ietf-discuss/2001Nov/0097.html
Well, you're taking that message out of context. But if that shoe fits,
wear it.
Maybe you should reread the response to your message:
http://lists.w3.org/Archives/Public/ietf-discuss/2001Nov/0098.html
For every clueful newbie who knows what he is talking about, knows the
limitations of his own experience, and just doesn't speak the same
language as more experienced IETFers, there are ten newbies who think
that the whole Internet works just like the tiny portion that they've
seen, and that other's experience is either irrelevant or a sign of
arrogance.
Every organization or group of people, to be successful, has to figure
out how to filter out people who work against it. Some of them have
formal entrance barriers, some of them have other means.
People who have been around here for awhile have learned to figure out
which newbies have the potential to make constructive contributions
(because they can learn from the experience of others, integrate it with
their own, and express the result in terms that make sense to others)
and which ones aren't likely to be able to do anything but get in the
way.
If I had to say it myself, the response pretty much says it all.
All this started with a simple pertinent question!
And you got a pertinent answer. You just didn't want to recognize it as
such.
--
He not busy being born, is busy dying. - Bob Dylan